|
|
Try messing with the windows styles. e.g.
HWND hWnd = ::CreateWindow("EDIT", "Hello", WS_POPUP|WS_VISIBLE, 0, 0, 100, 100, NULL, NULL, theApp.m_hInstance, NULL);
Makes window with no title bar and such.
Steve
|
|
|
|
|
Hi
I've created a MFC activeX control in vc++ 6.0. I am using that control in vb 6. I am catching the events fired by the control in the VB application. The problem
is that when i step through the application in VB i catch all the events thrown by the control however when i compile the application and run it i am unable to catch the events. Also when i debug the application in Visual C++ i can see that the events are being fired properly but VB application does not respond appropriately. Any body know why this might be happening?
Thanks
|
|
|
|
|
How to prevent a modal dialog from closing when we hit ESC key?
Thanks in advance,
Sarvan AL
|
|
|
|
|
Hi
While pressing ESC key by default ID_CANCEL(OnCancel) message is calling.
So write code inside OnCancel() to prevent this. Check the keypressed and if it is ESC key then dont call CDialog::OnCancel();
regards
Vallikumar A
|
|
|
|
|
Thanks Mr Vallikumar.
I've not thought of that.
Sarvan AL
|
|
|
|
|
vallikumar wrote: Check the keypressed and if it is ESC key then dont call CDialog::OnCancel()
OnCancel will be called when Esc is pressed or the Cancel button with the id IDCANCEL is clicked.
Jesus Loves <marquee direction="up" height="40" scrolldelay="1" step="1" scrollamount="1" style="background:#aabbcc;border-bottom:thin solid 1px #6699cc">
--Owner Drawn
--Nothing special
--Defeat is temporary but surrender is permanent
--Never say quits
--Jesus is Lord
|
|
|
|
|
The IsDialogMessage API provides this functionality. You would have to filter the messages passed to it - this will not be possible for dialog in general as you have not got access to the message pump. An alternative, if you can't use this technique, would be to use hooks (SetWindowsHookEx ).
Steve
|
|
|
|
|
|
The other guys have a point - My solution was like killing a gnat with a sledgehammer. Perhaps just use the GetAsyncKeyState to see if the escape key is down in a OnCancel overide.
|
|
|
|
|
Going after a gnat with a sledgehammer is always fun!
ZeePain! wrote: This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
thedailywtf.com[^]
|
|
|
|
|
The simplest solution is to override the PreTranslateMessage() ! Within the handler, write this code...
if(pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_ESCAPE)
wParam = NULL;
Simple as pie
Regards,
Rajesh R. Subramanian
You have an apple and me too. We exchange those and We have an apple each.
You have an idea and me too. We exchange those and We have two ideas each.
|
|
|
|
|
Ladies and gentlemen, we have a winner. It's one of those solutions that once you hear, you feel stupid for not thinking of (assuming MFC is beging used).
Steve
|
|
|
|
|
LOL man. that made you dig deep to set a system-wide hook? It does happen, but.
Regards,
Rajesh R. Subramanian.
You have an apple and me too. We exchange those and We have an apple each.
You have an idea and me too. We exchange those and We have two ideas each.
|
|
|
|
|
I would have only set a thread local hook - But regardless your solution is still the way to go.
Steve
|
|
|
|
|
no hooks are needed to do this.
-Prakash
|
|
|
|
|
I think we've established that - PreTranslateMessage was the best solution - Assuming we're using MFC.
Steve
|
|
|
|
|
|
|
toxcct wrote: thanks to mickael...
no doubt.
-Prakash
|
|
|
|
|
Tox, how is it much better? Do I write in thin air? If i edit OnCancel(), then will it not change the whole good functionality of the button? I accept, I edit the OnCancel() and the dialog won't close on pressing the Escape then what about clicking the cancel button dude? Don't tell me you did not know this. Please explain tox. I knew mike's solution already and still I think PreTranslateMessage is best.
Regards,
Rajesh R. Subramanian
You have an apple and me too. We exchange those and We have an apple each.
You have an idea and me too. We exchange those and We have two ideas each.
|
|
|
|
|
That approach seemed to stop the dialog box from begin closed by any means so I ruled it out. I don't actually remember him saying he uses MFC, but that seems to be assumed in this forum. I try to steer clear of MFC in my own projects although I use it extensively at work. The MFC source code is a valuable resource however.
Steve
|
|
|
|
|
Stephen Hewitt wrote: That approach seemed to stop the dialog box from begin closed by any means so I ruled it out.
you dont put for both onok and oncancel, just the oncancel will do in this case.
-Prakash
|
|
|
|
|
When I test just OnCancel and stopped it calling CDialog::OnCancel the dialog can't be closed by any means other the pressing "OK". This includes the "x", the system menu and escape.
Steve
|
|
|
|
|
I knew this other solution well before I had posted the PreTranslateMessage handling solution. But it will just change the functionality of OnCancel() too. If i write my code in OnCancel(), not to close, then on clicking the cancel button too, the dialog won't close. Don't tell me you did not know this please. I might want to do something else on OnOk() too. Handling the pretranslatemessage is not a big job. And its powerful than any other way when you work with MFC. I cannot think of any other easier and powerful way to do this. If you know something else which is REALLY APPROPRIATE and RELEVANT, please let us know too. Thanks in advance.
Regards,
Rajesh R. Subramanian
You have an apple and me too. We exchange those and We have an apple each.
You have an idea and me too. We exchange those and We have two ideas each.
|
|
|
|