The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: oex on March 23, 2011, 03:48:50 AM

Title: WM_AVOIDANCE
Post by: 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....
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 03:54:37 AM
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
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 03:59:37 AM
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
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 04:00:51 AM
it sounds to me like a message-only window is what you want, Peter
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 04:02:04 AM
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
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 04:02:23 AM
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....
Title: Re: WM_AVOIDANCE
Post by: hutch-- on March 23, 2011, 04:51:10 AM
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.
Title: Re: WM_AVOIDANCE
Post by: 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
Title: Re: WM_AVOIDANCE
Post by: hutch-- on March 23, 2011, 07:48:27 AM
Dave,

just merge the sections and it will drop to 1k.
Title: Re: WM_AVOIDANCE
Post by: jj2007 on March 23, 2011, 10:02:52 AM
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 ::)
Title: Re: WM_AVOIDANCE
Post by: sinsi on March 23, 2011, 10:22:44 AM
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?
Title: Re: WM_AVOIDANCE
Post by: Ghandi on March 23, 2011, 12:18:54 PM
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
Title: Re: WM_AVOIDANCE
Post by: 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
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 01:12:28 PM
Peter,
here is a hidden window
you can terminate it with the Task Manager   :P
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 01:15:05 PM
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
Title: Re: WM_AVOIDANCE
Post by: jj2007 on March 23, 2011, 01:26:18 PM
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.
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 23, 2011, 01:31:26 PM
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
Title: Re: WM_AVOIDANCE
Post by: qWord on March 23, 2011, 01:33:59 PM
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
Title: Re: WM_AVOIDANCE
Post by: baltoro on March 23, 2011, 04:15:14 PM
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
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 04:26:52 PM
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....
Title: Re: WM_AVOIDANCE
Post by: baltoro on March 23, 2011, 04:29:17 PM
...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 ???
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 04:41:45 PM
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
Title: Re: WM_AVOIDANCE
Post by: baltoro on March 23, 2011, 05:00:01 PM
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,...
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 06:34:46 PM
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)
Title: Re: WM_AVOIDANCE
Post by: oex on March 23, 2011, 06:40:05 PM
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....
Title: Re: WM_AVOIDANCE
Post by: Slugsnack on March 25, 2011, 12:48:52 PM
why don't you just use dialogs. way easier
Title: Re: WM_AVOIDANCE
Post by: oex on March 25, 2011, 01:32:55 PM
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....
Title: Re: WM_AVOIDANCE
Post by: oex on March 26, 2011, 11:43:22 PM
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
Title: Re: WM_AVOIDANCE
Post by: dedndave on March 27, 2011, 03:43:02 AM
http://www.masm32.com/board/index.php?topic=16305.msg134926#msg134926
Title: Re: WM_AVOIDANCE
Post by: oex on March 27, 2011, 03:47:51 AM
: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
Title: Re: WM_AVOIDANCE
Post by: 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
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
Title: Re: WM_AVOIDANCE
Post by: oex on March 27, 2011, 04:02:23 AM
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....
Title: Re: WM_AVOIDANCE
Post by: dedndave on April 01, 2011, 02:19:33 AM
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)