WM_THIS, WM_THAT.... I write a lot of console code but there are some things where I have to interface with windows which I dont want to have to write at an insanely low level and also dont want to create a window just to proces WM_ messages.... ie WM_DEVICECHANGED....
What is the simplest way to create a message handling proc for these.... Is there any problem with this from console? CreateDialogEx? CreateWindowEX? Something even simpler? Obviously I just need an invisible message handler and not a window....
lol
that stuff isn't so bad
anyways - Hutch has a program that might help
search for "Code Generator" or "ProStart" in the masm32 project sub-forum
it gets the code started for you - you just add in the things you need
i am not sure what you are trying to do
another term you might search is "message only" window
a window that handles messages, but displays nothing
Yeah atm I would use CreateWindowEx but it's annoying because you have about 20 lines of code to do a simple interface with windows.... I just wondered if there was a quicker and easier way of creating a hWnd and a messaging proc but still probably lower level than CreateDialog
it sounds to me like a message-only window is what you want, Peter
here is an example to get you started
http://www.masm32.com/board/index.php?topic=10266.msg75422#msg75422
but - a regular window isn't that bad
register a class
create the window
message loop
WndProc to handle messages
as i said, Hutch's ProStart will get it started for you
Perfect :bg ty.... At least better than I have got already with HWND_MESSAGE.... :lol still all the class struct crap but I minimise most of that already.... It's never neat and simple is it :lol....
All I want is to catch notification events but they require registration of windows I think....
Peter,
There is an old trick of starting a window off screen and using its message loop to do the stuff you have in mind. For the 4 co-ordinates just use negative numbers, -1024,-1024,500,400 and the window will start but you just don't see it. A bare "main" with an attached WndProc() is very simple code and its small as well. If you want it to run on later OS versions a manifest and version control block are more or less necessary.
have a look at the "masm1k" example in the example code, you cannot do it smaller.
184 bytes of code.... (i.e. not counting data)
i am sure it could be smaller :bg
Dave,
just merge the sections and it will drop to 1k.
Quote from: dedndave on March 23, 2011, 04:58:58 AM
184 bytes of code.... (i.e. not counting data)
i am sure it could be smaller :bg
INVOKE CreateWindowEx,edi,esi,offset AppName,
WS_OVERLAPPEDWINDOW or WS_VISIBLE or WS_CLIPCHILDREN,
CW_USEDEFAULT,SW_SHOWNORMAL,400,300,edi,edi,ebx,edi
Y=SW_SHOWNORMAL happens to be 1 ::)
Quote from: oex on March 23, 2011, 03:48:50 AM
WM_THIS, WM_THAT.... I write a lot of console code but there are some things where I have to interface with windows which I dont want to have to write at an insanely low level and also dont want to create a window just to proces WM_ messages.... ie WM_DEVICECHANGED....
What is the simplest way to create a message handling proc for these.... Is there any problem with this from console? CreateDialogEx? CreateWindowEX? Something even simpler? Obviously I just need an invisible message handler and not a window....
Maybe go the other way, make a window then create a console?
What about getting a handle to the console window and subclassing its window proc to point at yours, pass the messages you don't want to process to the original handler and process the ones you do want to.
*EDIT* Scratch that, i have only donea simple test but it appears that changing the WndProc is not allowed from a Console app...
HR,
Ghandi
Jochen,
QuoteY=SW_SHOWNORMAL happens to be 1 ::)
QuoteIf an overlapped window is created with the WS_VISIBLE style bit set and the x parameter is set to CW_USEDEFAULT,
then the y parameter determines how the window is shown. If the y parameter is CW_USEDEFAULT, then the window
manager calls ShowWindow with the SW_SHOW flag after the window has been created. If the y parameter is some
other value, then the window manager calls ShowWindow with that value as the nCmdShow parameter.
he was looking for a way to hide the window
so, it could be SW_HIDE
Peter,
here is a hidden window
you can terminate it with the Task Manager :P
Ghandi,
Quotei have only done a simple test but it appears that changing the WndProc is not allowed from a Console app...
i think if you run an app, shell the cmd.exe window (so that your program is the owner), then use SetClassLong, you can do it
haven't had a chance to try it - it's on my list :P
Quote from: dedndave on March 23, 2011, 12:19:44 PM
Jochen,
QuoteY=SW_SHOWNORMAL happens to be 1 ::)
QuoteIf an overlapped window is created with the WS_VISIBLE style bit set and the x parameter is set to CW_USEDEFAULT,
then the y parameter determines how the window is shown. If the y parameter is CW_USEDEFAULT, then the window
manager calls ShowWindow with the SW_SHOW flag after the window has been created. If the y parameter is some
other value, then the window manager calls ShowWindow with that value as the nCmdShow parameter.
he was looking for a way to hide the window
so, it could be SW_HIDE
Win32.hlp:
QuoteIf an overlapped window is created with the WS_VISIBLE style bit set and the x parameter is set to CW_USEDEFAULT, Windows ignores the y parameter.
So they changed either the doc, or the behaviour. Interesting.
win32.hlp is very old :P
i am guessing it was an error in the doc
if you search the forum, you can find a thread where they were playing with it - and tested it on different OS's
here an variant of message-only-window by using an predefined window class:
Quoteinclude masm32rt.inc
.data?
pcbWndProc PVOID ?
.code
MsgProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg == WM_xyz
.else
invoke CallWindowProc,pcbWndProc,hWnd,uMsg,wParam,lParam
ret
.endif
xor eax,eax
ret
MsgProc endp
main proc
LOCAL msg:MSG
mov esi,rv(CreateWindowEx,0,"Button",0,0,-1000,-1000,100,100,0,0,rv(GetModuleHandle,0),0)
mov pcbWndProc,rv(GetWindowLong,esi,GWL_WNDPROC)
invoke SetWindowLong,esi,GWL_WNDPROC,OFFSET MsgProc
.while 1
invoke GetMessage,ADDR msg,0,0,0
.break .if !eax || eax == -1
invoke TranslateMessage,ADDR msg
invoke DispatchMessage,ADDR msg
.endw
invoke ExitProcess,0
main endp
end main
If you are really a cool programmer (like me), it's a simple thing to keep a number of source code files handy that constitute a skeleton Windows application (or, template).
...And, if you are incredibly lazy (again, like me), you can just start a new project in Visual Studio (or, the MASM editor. if you MUST do it in assembly language), and, select, 'Insert file as text' from the menu,...and, you have all your basic code and pre-defined custom windows messages (WM_USER and greater) with many lines commented out, so it initially compiles correctly,...and, you just selectively uncomment whatever you need. It couldn't be easier.
Of course, this is not an original idea,...I stole it from other lazy programmers,...
:bg Even, a trilobite could do this without generating errors. :bg
Quote from: baltoro on March 23, 2011, 04:15:14 PM
And, if you are incredibly lazy (again, like me)
Yep you hit the nail on the head.... I'm so lazy I cant be arsed to do the windows handler code.... I take offense that I must use COM or create hWnds for event handlers when a function call or callback function would suffice :lol....
...Clearly, you are pushing the envelope on the lazy thing,...
...how about hiring a houseboy (as in the Pink Panther movies) that can produce adequate assembly language files ???
Quote from: baltoro on March 23, 2011, 04:29:17 PM
Pink Panther
Aha.... I see what you are doing.... You are trying to further obfuscate Google's understanding of the principle reasoning behind the universal physical laws of Purple Nano Unicorn (http://www.masm32.com/board/index.php?topic=16304.msg134881#msg134881) Theory....
You must be careful pursueing this line of devious and coercive misrepresentation Baltoro it could get us graveyarded :lol
Don't worry. I am an incredibly lazy and inept programmer. :bg
... But,...my real claim to fame is generating: PORN ALERTS,...
...For which, I take full responsibility,...
As always we must remain vigilent the Jeopardy machine has access to all our intel....
Coercive Mind Control Tactics (http://www.factnet.org/coercivemindcontrol.html)
IS SOMEONE TRYING TO ETHICALLY OR UNETHICALLY INFLUENCE YOU? (http://www.factnet.org/rancho4.htm)
Donkey's Stable (http://www.quickersoft.com/donkey/index.html)
Quote from: qWord on March 23, 2011, 01:33:59 PM
here an variant of message-only-window by using an predefined window class:
Nice 1 I see the logic and it is an improvement on what I have though although my stated aim was to reduce code I should have also specified my desire to also not jump through unnecessary M$ hoops.... I find it incredible that while M$ will gladly send out notifications to hundreds of windows that have no interest in them they dont provide callback functions....
why don't you just use dialogs. way easier
Yep, I finally settled on a variant of qWords code with HWND_MESSAGE in the end.... Dialogs were a possibility however I didnt want to create a window unneccesarily.... Ultimately I was hoping that there was a way to 'fake' a windows hWnd and/or bypass functionality which windows has built which requires a hWnd passed to it easily....
I already have a window in my program however I wanted a seperate window specifically for processing certain messages as this window doesnt load by default....
Slight update....
Quote
A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.
In other words a HWND_MESSAGE only window is useless to the task :lol
http://www.masm32.com/board/index.php?topic=16305.msg134926#msg134926
:lol thanks.... I have ended up with:
mov ebx, alloc(SIZEOF WNDCLASSEX)
mov [ebx].WNDCLASSEX.cbSize, SIZEOF WNDCLASSEX
mov [ebx].WNDCLASSEX.lpfnWndProc, OFFSET MsgProc
mov [ebx].WNDCLASSEX.hInstance, 400000h
mov [ebx].WNDCLASSEX.lpszClassName, chr$("MC")
invoke RegisterClassEx, ebx
CreateWindowEx, 0, chr$("MC"), chr$("MC"), 0, 0, 0, 0, 0, 0, 0, 400000h, 0
It works.... It may be missing essencials however :lol
yah - i think it's missing a few things
if you take that Hidden program, it would be easy to add handling of WM_DEVICECHANGE to the WndProc
WndProc PROC hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
mov ecx,uMsg
cmp ecx,WM_DEVICECHANGE
jz DevChange
cmp ecx,WM_DESTROY
jz WndPrZ
;------------------------------
;unhandled messages come here
;the return address and 4 parms are already on the stack
;if you push EBX, EBP, ESI, or EDI, be sure to pop them
leave
JMP DefWindowProc
;------------------------------
;WM_DEVICECHANGE
DevChange:
;code here - refer to DBT_DEVICEARRIVAL documentation
;------------------------------
;exit with 0
WndPr0: xor eax,eax
ret
;------------------------------
;WM_DESTROY
WndPrZ: INVOKE PostQuitMessage,NULL
jmp WndPr0
WndProc ENDP
if you are using it the way i think you are, you could remove the WM_DESTROY code
Quote from: dedndave on March 27, 2011, 03:55:51 AM
yah - i think it's missing a few things
if you take that Hidden program, it would be easy to add handling of WM_DEVICECHANGE to the WndProc
Yep already tested and working with the code I just posted.... (I excluded the loops etc and just posted the 'guts' :lol)....
The missing bits might be things like Icon and CreateWindowEx params however as the window doesnt get drawn I dont see that this would be necessary....
I already had most of the code in the program's main window however this window is not always loaded hence the minimal window on a seperate thread....
Peter,
i had a need for a hidden window, as well
in my case, i wanted the hidden window to run a visible one
and, i wanted them to be able to communicate back and forth
once each window has the handle to the other, it is pretty simple
the user opens the hidden window
it runs the visible window, passing the handle on the command line
the visible window then sends its' handle back to the hidden window via WM_COPYDATA
once the handles have been exchanged, the hidden window can revector the WM_COPYDATA handler for other messages
closing the visible window sends a message to the hidden one to close also :P
(the visible window .EXE is renamed as .BIN, and can be in any PATH'ed folder)