|
Dong-Jun Kim wrote: Is it normal behavior of modeless dialog boxes?
"Normal" is whatever you make of it.
Dong-Jun Kim wrote: I just want to close the box when I click close, little x button on top right, button.
Then you simply need to call DestroyWindow() in those situations. Be careful that you are not inadvertently calling EndDialog() .
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I have a worker thread that needs to wait a certain amount of miliseconds before resuming..
I would just got the for(i=0; i<10000000000; i++) route, but i'm afaid it will eat up the CPU. I'm trying to stay out of a loop but stay in the worker thread.
I need my main thread to be very alert and time accurate while this worker thread is waiting.
I've looked at all the timer functions.. can't seem to find the one to do the trick..
any ideas.. ?
Workthread()
{
//do some processing
//wait
//do more processing
//return
}
|
|
|
|
|
Sleep[^]
Although why someone is writing multi-threaded code prior to learning the threading API's is... well .... pretty crazy.
led mike
|
|
|
|
|
On Windows, try Sleep(milliseconds)
Eats NO CPU
|
|
|
|
|
HA! Beat you by the click of an eye.
led mike
|
|
|
|
|
|
duh... didn't have the time.h header in... my bad.. thanks guys
|
|
|
|
|
aquawicket wrote: duh... didn't have the time.h header in... my bad.. thanks guys
try more efficient WaitForSingleObject with retrun value WAIT_TIMEOUT
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief And You
|
|
|
|
|
Hello.
I have added a picture control to my dialog application resource file.
I dont know how to access it at run time.
I thought you would need a pointer, in the same way you access a Edit control:
CEdit *p = GetDlgItem(IDC_EDT);
p->whatever,
etc.
So I need a pointer to the control I assume in order to send an image to it.
Can anyone help.
Jerry
|
|
|
|
|
Try a pointer to a CStatic object
Mark
|
|
|
|
|
|
That is the type of control placed on the dialog.
You can set a bitmap into it in the designer or at runtime with CStatic::SetBitmap()
|
|
|
|
|
By default, the control has an id of IDC_STATIC . Change that to something else. Then use ClassWizard (Ctrl+W) to associate a CStatic object to that control. Then you can call the SetBitmap() method.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thank you for your help.
Jerry
|
|
|
|
|
Static control is good for show picture but why you want to use Edit Ctrl
|
|
|
|
|
Hi,
I have written a piece of code in WM_KEYDOWN for the tab key when the tab key is pressed in the edit box.It does what it is supposed to do but before that the tab key shifts the data in the edit box 4 spaces ahead usually what a tab key does.
To stop the tab key from its natural behaviour what should be overridden?
Thanks a ton.
Prithaa
|
|
|
|
|
Did you try overriding the PreTranslateMessage
|
|
|
|
|
Hi,
No I have not tried PreTranslateMessage.
So,What Should I do in PreTranslateMessage()
Prithaa
|
|
|
|
|
if(pMsg->message==WM_KEYDOWN && pMsg->wParam==VK_TAB)
pMsg->wParam=NULL;
This way we are handling the message before it is dispatched to the TranslateMessage and DispatchMessage Windows functions. In short, this will completely nullify the effect of tab key within your dialog.
|
|
|
|
|
Hello,
Thanks
It worked.
Prithaa
|
|
|
|
|
prithaa wrote: Thanks
You're welcome.
The nail that stands out will be hammered down
|
|
|
|
|
prithaa wrote: Thanks
It worked.
Prithaa
IMHO.. I never liked Switch case and If statement in PretranslateMessage.. i believe you should create handller for Wm_KEYDOWN!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief And You
|
|
|
|
|
Can someone explain this to me please? I'm trying to understnad the code snippet below. This function is actually used to form a complete message that you can send on the serial com port using the win32 file function WriteFile.
However I'm getting a bit confused trying to work out what the final string would be if the initial value of DWord is 256. I've attached my current working below the code. Any help would be greatly appreciated.
Code Snippet
typedef unsigned int DWORD;
typedef unsigned short WORD;
// Convert DWORD to a 4 characters long string, not null terminated.
// Little-endian is used.
string
DWORDToString(DWORD dword)
{
string str = "1234";
str[0] = (char)((dword >> 0) & 0x000000ff);
str[1] = (char)((dword >> 8) & 0x000000ff);
str[2] = (char)((dword >> 16) & 0x000000ff);
str[3] = (char)((dword >> 24) & 0x000000ff);
return str;
}
My Working.....
Initial value of DWord = 256
Binary equivalent = 1 0000 0000
Hex equivalent = 100
str[0] = (char)((dword >> 0) & 0x000000ff);
1 0000 0000 Right shift >> 0 gives 1 0000 0000
Hex = 0x000000ff
Binary = 1111 1111
1 0000 0000
1111 1111
----------------
0 0000 0000
Str[0] = 0 == 0x00
str[1] = (char)((dword >> 8) & 0x000000ff);
1 0000 0000 Right shift >> 8 gives 0000 0001
Hex = 0x000000ff
Binary = 1111 1111
0000 0001
1111 1111
----------------
0 0000 0001
Str[1] = 1 == 0x01
str[2] = (char)((dword >> 16) & 0x000000ff);
1 0000 0000 Right shift >> 16 gives 0000 0000 0000 0001
Hex = 0x000000ff
Binary = 1111 1111
0000 0000
1111 1111
----------------
0000 0000
Str[2] = 0 == 0x00
str[3] = (char)((dword >> 24) & 0x000000ff);
1 0000 0000 Right shift >> 16 gives 0000 0000 0000 0000 0000 0001
Hex = 0x000000ff
Binary = 1111 1111
0000 0000
1111 1111
----------------
0000 0000
Str[3] = 0 == 0x00
|
|
|
|
|
What output were you expecting from your function? Compare that output to the actual output, how do they differ?
|
|
|
|
|
The function is just ensuring that the bytes are in little-endian order no matter what processor
it's running on.
On an x86 machine you could just do this
string
DWORDToString(DWORD dword)
{
string str = "1234";
*((DWORD*)(&str[0])) = dword;
return str;
}
but it wouldn't be the same on a processor that stores 32-bit integers in big-endian order.
The function
Takes the low-order 8 bits and puts it at index 0 position in the array
Takes the next highest order 8 bits and puts it at index 1 position in the array
Takes the next highest order 8 bits and puts it at index 2 position in the array
Takes the highest order 8 bits and puts it at index 3 position in the array
I don't know if this was a typo but
1 0000 0000 Right shift >> 16 gives 0000 0000 0000 0001
is wrong. Should be
1 0000 0000 Right shift >> 16 gives 0000 0000 0000 0000
1 0000 0000 Right shift >> 24 gives 0000 0000 0000 0000
|
|
|
|