|
I'm not sure if I correctly understand the question but I suppose you have some problems with dialog data exchange (DDX) architecture. If this is the case check out this[^] and this[^] MSDN pages.
Also have a look at this[^] example. I believe it can be useful for you.
|
|
|
|
|
There's a nice article written by toxcct, here at CodeProject: Dialogs Communication[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Are the dialog boxes "peers" or "subordinates?" It's much the same either way, but it might help to clarify your question if you provided such details.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi,
I need to draw shadow aroung the rounded dialog, How can I do that?
|
|
|
|
|
First, have a look at this[^] article.
Another option is using CS_DROPSHADOW class but it requires a Windows version >= XP.
And finally, check out this[^] article.
Choose the most appropriate approach for you.
|
|
|
|
|
To Get the Current UserName and HostName in vc++ mfc
char host[200];
gethostname(host,201);
CString str,user;
str=host;
TCHAR acUserName[100];
DWORD nUserName = sizeof(acUserName);
GetUserName(acUserName, &nUserName);
user=acUserName;
Regards,
N.GokulNath
|
|
|
|
|
Please do not re post the same question...
I believe in LOVE AT FIRST SITE...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
And your question is?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi,
Urgent
I'm current a full-time student doing my Final-Year Project.
I seeking for H.E.L.P and C.O.A.C.H.I.N.G Badly
Requirements:
I was assigned to come out a program using Visual C++ to communicate with HyperTerminal thru RS232 Serial Cable.
PC(1) opens Hyperterminal to send text to PC(2) which opens Visual C++, a program to receive the text and able to view the text on the screen thru a RS232, Null Modem Cable - Serial Communication.
Progress:
what I had done so far is only allowing me open Visual C++ PC(2) to send text to PC(1) Hyperterminal instead in another way on the requirements I need as mentioned above.
Regards,
david
|
|
|
|
|
Please use cross serial cable.
and communication setting should be same.
eg: baudrate , parity, stop bit etc.
u can use either hyperterminal or Look Rs232.
my suggestion is that please use Look RS232.it gives more option to see send and receive data.
|
|
|
|
|
Thanks on your recommentation..
on your recommentation, does that apply on coming out a program using Visual C++ to receive the text from Hyperterminal?
|
|
|
|
|
FYI: I have been using this virtual null modem[^] successfully; it allows you to run both programs on the same computer, having each of them use a virtual serial port which get interconnected using the virtual null modem. So you no longer need two PC systems...
|
|
|
|
|
Hi, the problem is that the bytes what i get logged are disordered and not in proper row and somehow they are even splited.
I used apimonitorig software and monitored readprocessmemory and sawed that it holds byte rows for sure this was the output from apimonitorig software : lpBuffer 0x014D0020: {4D 5A 90 00 03 00 00 00 04 00 00 00
This is my hooked readprocessmemory where i am trying to log the lpBuffer what is holding byte rows.
BOOL (__stdcall* pReadProcessMemory)(HANDLE hProcess, LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);
BOOL __stdcall hookedReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead)
{
bool returning = pReadProcessMemory(hProcess, lpBaseAddress, lpBuffer, nSize, lpNumberOfBytesRead);
char* mybytes = (char*)lpBuffer;
for (int i = 0; i < nSize; i++)
Log( "lpBuffer: %x \n", mybytes[i]);
return returning;
}
And the log output is like this:
lpBuffer: 4d
lpBuffer: 5a
lpBuffer: ffffff90
lpBuffer: 0
lpBuffer: 3
lpBuffer: 0
lpBuffer: 0
lpBuffer: 0
lpBuffer: 4
lpBuffer: 0
lpBuffer: 0
lpBuffer: 0
lpBuffer: ffffffff
lpBuffer: ffffffff
lpBuffer: 0
lpBuffer: 0
lpBuffer: ffffffb8
Please help what i am doing wrong im out of ideas
|
|
|
|
|
nah1337 wrote:
char* mybytes = (char*)lpBuffer;
Change it to :
unsigned char* mybytes = (unsigned char*)lpBuffer;
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Hi, it did not make any difference the log is still same:
Here is the output
lpBuffer: 4d
lpBuffer: 5a
lpBuffer: 90
lpBuffer: 0
lpBuffer: 3
lpBuffer: 0
lpBuffer: 0
lpBuffer: 0
lpBuffer: 4
lpBuffer: 0
lpBuffer: 0
lpBuffer: 0
|
|
|
|
|
I'm sorry but I don't see what is wrong with this ouptut; it is the same sequence of bytes shown in your orignal message as received in your memory buffer.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I wanted to log them straight out i mean like in row not as separated like my log functions does it, but if that is impossible then its ok for me.
|
|
|
|
|
nah1337 wrote: wanted to log them straight out i mean like in row
Well, it's just a matter of correcting your code so that you do not log each item on a separate line.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Hi to everybody,
I am creating a native win32 dll with the following function.
LPCWSTR __stdcall DisplayInfo()
{
wchar_t* hello =_T("Yahoooooooooo!");
return (LPWSTR)hello;
}
Program compiles successfully. But when i use it in my visual basic application, the entire IDE crashes.
Private Declare Function DisplayInfo Lib "dllexample1" () As String
Private Sub Command1_Click()
MsgBox DisplayInfo
End Sub
Help?????
:: Roses ::
|
|
|
|
|
I'm no expert, but I do not think you can call a C++ function directly like this, and expect a String to be returned. I would suggest posting your question in the Visual Basic forum, as someone there will probably know the answer.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
The hello string is a local variable within the DisplayInfo() function; so when you return, the memory is freed. You return a pointer to the string, but the string's memory got overwritten.
To fix this this particular problem, you could make hello a static variable; this will keep its address valid after returning.
Another, more generally usable way would be to pass a string variable to DisplayInfo() and copy hello 's content to it inside the function.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
Actually, in this particular case, the local variable points to a string literal that is, of course, not freed.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I wouldn't be too sure about that. The variable hello is not declared const, so it would be valid to modify the content of this string later in the code like this:
hello[3]=0;
This means the compiler does have to create a local string variable on the stack, inside this function. And this particular string variable will indeed be destroyed upon return.
You might argue that there is no such modification, but since the function itself passes a (non-const) pointer to this string, the caller might modify the contents instead! Also, later calls to that function need to initialize hello with the original string, not an address to a presumed literal which in the meantime might have been changed to god knows what. So what you'll want to pass is a copy of the literal being used for intialization, not the address of the literal itself!
|
|
|
|
|
Stefan63 wrote: This means the compiler does have to create a local string variable on the stack, inside this function. And this particular string variable will indeed be destroyed upon return.
You are wrong, at least on Microsoft compiler, these strings have static storage duration, see http://msdn.microsoft.com/en-us/library/0h227906.aspx[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Duh
Microsoft wrote: Microsoft Specific
You win
P.S.:
if a DLL uses a static variable, and gets called just once, will the variable be released after the last (and only) call, or at the end of the lifetime of the application that calls it?
I'm pretty sure about a C++ app calling a C++ DLL; but not so much about another language app that might use other DLL bindings...
|
|
|
|