Well, here is the basic concept of what I want to do. I basically want to have a "wrapper" (I think this is what it is called) that has all of my variables which will be passed upon calling it. This is what it would look like (not complete).
WIN_CREATE PROC hInst:HINSTANCE, hPrevInst:HINSTANCE, CommandLine:LPSTR, CommandShow:DWORD, hIcon:DWORD, lpszCaption:DWORD
Now my question is that in the WNDCLASSEX Structure there is lpfnWndProc which is referenced by
mov wc.lpfnWndProc, OFFSET WndProc
Now if I wanted to add this into my WIN_CREATE PROC statement what would I put there
wndPROC:????????
I hope this explains what I want to do and someone will be able to help cause I have exhausted my brain already. Thanks.
Jason
Jason,
If you have masm32 up and working, create a skeleton file using the "prostart" code generator then have a look at how its done as it is similar to what you are asking. It uses a remote procedure for the WNDCLASSEX structure and the following RegisterClassEx call.
Once you have the class registeed for the Window, it then does a normal CreateWindowEx() call.
One of the things you will find is that you don't need to create a WinMain as you must provide the arguments to it yourself anyway. You get the instance handle with GetModuleHandle() and the comand line if you need it with GetCommandLine().
What is "prostart"?
I have been using the WinMain just to get started but I wanted to branch out from that and start creating my own functions to it. Thanks
Jason
if i understood you correctly, you just want to have address of wnd proc as a parameter?
WIN_CREATE PROC hInst:HINSTANCE,... etc. ..., AddressOfWndProc:DWORD
....
mov eax,AddressOfWndProc
mov wc.lpfnWndProc,eax
...
invoke WIN_CREATE, hInstance,... etc. ..., offset WndProc
Yes you are correct. I am guessing your saying it is a DWORD value?
Thanks for the help I got it working. Here is what it basically looks like.
- This is my main.asm
; ################################################################
.386
.model flat, stdcall
option casemap : none
; ################################################################
include Virtually.inc
; ################################################################
START:
invoke InitCommonControls
invoke GetModuleHandle, NULL
mov hInstance, eax
invoke GetCommandLine
mov CmdLine, eax
invoke WIN_CREATE, hInstance, NULL, CmdLine, SW_HIDE, 1, ADDR AppName, OFFSET WndProc, 10, 10, 700, 700
invoke ExitProcess, eax
end START
- This is my Virtually.inc file
.CODE
WIN_CREATE PROC hInst:HINSTANCE, hPrevInst:HINSTANCE, CommandLine:LPSTR, CommandShow:DWORD, hIcon:DWORD, lpszCaption:DWORD, AddressOfWndProc:DWORD, posX:DWORD, posY:DWORD, posW:DWORD, posH:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hwnd:HWND
mov wc.cbSize, SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov eax, AddressOfWndProc
mov wc.lpfnWndProc, eax
mov wc.cbClsExtra, NULL
mov wc.cbWndExtra, NULL
...........................................
..........................................
invoke CreateWindowEx, WS_EX_CLIENTEDGE, ADDR ClassName, lpszCaption, WS_OVERLAPPEDWINDOW, posX, posY, posW, posH, NULL, NULL, hInst, NULL
mov hwnd, eax
invoke ShowWindow, hwnd, CommandShow
invoke UpdateWindow, hwnd
.WHILE TRUE
invoke GetMessage, ADDR msg, NULL, 0, 0
.BREAK .IF (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDW
mov eax, msg.wParam
ret
WIN_CREATE endp
What I ended up having to do was move my WndProc out of my .asm file into my .inc file in order for this to work appropriately. Thanks for all the help.
Jason
After getting all of it straightened out I understand now why this is not the best method. I guess I will go to the Dialog calls now. :U
Quote from: jbullard on August 23, 2006, 02:13:56 AM
I am guessing your saying it is a DWORD value?
everything is dword :bg
you can also have WNDCLASSEX as initialized struct in .data
.data
wc WNDCLASSEX <sizeof WNDCLASSEX,CS_HREDRAW or CS_VREDRAW,offset WndProc,\
0,0,400000h,0,0,COLOR_WINDOW,0,offset ClassName,0>
ClassName db "MainWinClass",0Quote from: jbullard on August 23, 2006, 05:54:20 AM
After getting all of it straightened out I understand now why this is not the best method. I guess I will go to the Dialog calls now. :U
yes, dialogs are easier to work with...
Quote from: jbullard on August 22, 2006, 11:51:37 AM
What is "prostart"?
The tool comes with the Masm32 package :
C:\masm32\pstold.exe
@drizz
Yea. I ended up going with a dialog box to retrieve input. The only bad thing is that I have so many dialog boxes that it gets kinda redundant. I noticed that you put the WNDCLASSEX in a struct. Can you do the same for a dialog box? I currently have that MyDialog setup in the resource file which from what I have read is the best way to do it.
@Vortex
Thanks for the location
Thanks,
Jason
Jason,
There are two of them, the older one that Vortex mentioned that is lower level in its code output and the later version called pstart4.exe that uses more of the masm32 macro system. They pop templates fast enough to allow you to have a quick look at how this stuff hangs together so you can easily produce the stuff you want to design yourself.
The older one is closer to the old style C templates just so you get the mechanics of how a basic window hangs together. Normally for a basic window you must create a window class by loading the WNDCLASSEX structure, registering the class then calling the CreateWindowEx() function then you call ShowWindow/EnableWindow to make sure it displays correctly.
You put the correct address of the message handling callback into the WNDCLASSEX structure so that the message for that window are sent to the correct procedure.
Something to keep an eye on, during the CreateWindowEx() call it runs the code in the WndProc for the WM_CREATE message and until it returns the window handle returned by CreateWindowEx() is not valid. In the WM_CREATE processing you must use the handle from the stack parameters for the Wndproc.
So will Dialogs take Visual Styles? If so, how? Also, if I create a main window and a tray icon, when I click on a menu item which creates another window, how do you get Visual Styles on that window as well? These are basically the deciding factors on which way I go. I know I can InitCommonControls and use an XML doc to initialize Visual Styles which I already have setup, however, if I create a button on another window it does not have visual styles.????
Thanks,
Jason
Quote from: jbullard on August 24, 2006, 10:31:34 AM
however, if I create a button on another window it does not have visual styles.????
Use Hide/Unhide (ShowWindow) instead.
I do not know if i get this corectly, are you trying to use something like MFC with masm?
Anywindows has styles, have a win 32 API reference close by and read the functions that create the controls or windows or dialogs wuch is the same.
Anyway, AFAIK you define any "window" style whe you define its "class". A window class is simply a collection of data, thus a structure, with wich you declare the windows atributes, or better said you tie the "lose ends" of a window(such as window styles; callback function; mouse pointer etc) with your application(module). Dialogs, common controls(like an edit box or list view) are windows, it can be confusing but actually its not. They all have styles and a callback function that processes messages sent to them. I do not know yet how to "skin" your own windows since i didn't need it so far.
Iczelions Tutorials cover quite a large part of win32api programming, if not all by theory and example(and a few typos :P)
Hutch and Iczelion made all of this possible and of couse hutch is right :) the best way to do it is follow the canonical way of creating a window app: fill a WNDCLASS(EX) structure, RegisterWindow(Ex) it, CreateWindow(Ex), test its return if you wish, [call ShowWindow(), UpdateWindow() not absolutely necessary unless you are processing WM_PAINT in a certain way perhaps], enter an infinite loop that processes the messages sent by the callback procedure of your window. This seems a bit overhead but you'll be doing it a lot in win32api so its two way from here: learn the steps and use a skeleton file or learn the steps and all teh insides and outsides of this(wich is not too much overhead) wich allows you to enter advanced win32api programming by using lots of its stuff and customize any source that falls into your hands thus freeing you from dragging a skeleton file after yourself.
Furthermore i recomend Programming Windows 5th edition, Charles Petzold; its a bible for win32api programming and style.
To get Windows XP Visual Styles on your windows, you need to include a manifest file (Google it - "windows xp style manifest").
Either name it the same name as your executable + ".manifest" (ie. "myprog.exe.manifest") or include it in a resource file as RT_MANIFEST (24).
Example resource file and manifest attached.
Cheers,
Zooba :U
[attachment deleted by admin]
Jason,
Have a look at an example in the masm32 example code called MASM1K. (masm32\examples\exampl08\masm1k) It is pretty close to the bare bones of what it takes to make a window and in fact it is a very small amount of code. The virtues of this OS based technique is that it is self contained and very efficient in size terms. The window styles can be extracted out of the Microsoft reference material for CreateWindowEx() and you have both the extended styles (the 1st argument) and the normal windows styles which are ORRED together in the normal manner to produce the end result that you want.
Dialogs internally do the same thing but have additional code for keyboard handling and font size based scaling. The internal dialog engine in Windows is a good compromise if you need a controls style interface with buttons and the like as components. You can create dialog interfaces with either a dialog editor that produces an RC script that you compile using RC.EXE or alternatively you can use an OS based technique that build dialogs from in memory templates, this method has been developed in the masm32 project and has a set of supporting macros to make it easy to use.
The fun part if this is the direction you are going in is you can encapsulate complete windows, custom controls and the like in object modules built in masm and then use them with VC as the format is the same.
@zooba
Yeah, luckily I have been using Visual Styles in manifest files ever since VB6 so I definitely know my way with them. That was the first thing that I tried to do in discovering MASM and learning to create Windows. Once I found out that it would work I was like man, this is so much easier and faster than what I had learned before. :dazzled:
@hutch
What I ended up doing was removing the dialogs and extra windows and just went to one window. I think I need to learn everything with one before going on with more. However, I will keep that in the back of my mind as I progress. Thanks.
Jason