I'm at my wits end. (Started a new thread.) (Solved. Stupid comma.)

[Shooter]

I'm at my wits end trying to figure this out. I'm hoping someone out there can help me identify my faults. All I wanted to do was to take an example from the MASM32 world and convert it to GoASM using RadASM 3.x. So far, all I've managed to do is pull my hair out.

My latest build has developed even more quirks and bugs that I can't seem to figure out.



Would someone please take a look at my project and tell me what I'm doing wrong?

I very much appreciate any help I can get.
Thanks,
-Shooter

[Tight_Coder_Ex]

Let's clean it up step by step until it's working properly and we need to begin the DlgProc

Code Select Expand

DlgProc FRAME hWin,uMsg,wParam,lParam
LOCAL ts:TC_ITEM

**** ENTER CONTIONAL HERE TO DETERMINE IF MESSAGE IS "WM_INITDIALOG" ***

.WM_INITDIALOG
cmp D[uMsg],WM_INITDIALOG
jne >>.WM_NOTIFY

What is happening here, is that every message is being passed to WM_NOTIFY except WM_INITIDIALOG.  This is why the app hangs as it doen't respond properly to WM_DESTROY or WM_QUIT

[Shooter]

What is happening here, is that every message is being passed to WM_NOTIFY except WM_INITIDIALOG.  This is why the app hangs as it doesn't respond properly to WM_DESTROY or WM_QUIT

I'm not sure I follow what you're saying. Isn't that what needs to happen? Do I need to add conditionals for the WM_DESTROY and WM_QUIT messages?

[Tight_Coder_Ex]

Sorry about that, not being used to GoAsm, I didn't immediately see the logic.  In any event;

1.  App gets hung on WM_PAINT, for the main window, but window is not visible.  Suspect resource template incorrect
2.  Your missing code to handle WM_COMMAND, but because the main window doesn't display, mute anyway
3.  There are quite a few inconsistencies, between the original and what you've done, espcially in the resource files.

Go through everything and make sure your doing it the same as the original and I'm sure you'll find the problem.

[Shooter]

Question about the resource editor in RadASM 3.x:

Does the number in the xStyle have greater or lesser importance than the settings of each of the other variables?

If I set the xStyle number to 50000000 for the 1st tab (40000000 for the 2nd and 3rd tabs), and then set the Border to 'Flat', the xStyle reverts to D0000000 for the 1st tab (C0000000 for the 2nd and 3rd tabs). This does not happen in RadASM 2.x.

3.  There are quite a few inconsistencies, between the original and what you've done, especially in the resource files.

That's just the thing. I've gone over and over and over the code and haven't found anything that sticks out.

[Tight_Coder_Ex]

I've compiled the original and linked it without modification and it worked as expected, so there has to be something you've missed.
I'm not familiar with the tools you're using, so can't be of much help there

[Shooter]

It took me a while to figure out why I kept getting this error when attempting to compile the original MASM32 demo project in RadASM 3.0.0.7g:

Code Select Expand

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

It turns out that in RadASM the default set of paths for masm was .\masm\ instead of .\masm32\. Once I changed that everything compiled correctly AND just like you, the program does as advertised.

But I still haven't found why my conversion to GoASM has failed so miserably.

Sadly, based upon my experiences I think I'm just about to give up on GoASM. MASM32 seems to be more widely accepted, documented, and supported.

[dedndave]

i thought *Witt's End* was an anteroom in a cave   :P

[Shooter]

i thought *Witt's End* was an anteroom in a cave   :P

Always the funny one, you are.

[ramguru]

The problem is obvious, default messages are not handled in any of the 4 procedures.

Code Select Expand


Tab2Proc FRAME hWin,uMsg,wParam,lParam

cmp D[uMsg],WM_INITDIALOG
jne >.WM_DEF ; on last message
; do stuff
jmp    >.EndTab2Proc
.WM_DEF
xor    eax, eax
ret
.EndTab2Proc
mov eax,TRUE
ret

endf



[Shooter]

The problem is obvious, default messages are not handled in any of the 4 procedures.

Code Select Expand


Tab2Proc FRAME hWin,uMsg,wParam,lParam

cmp D[uMsg],WM_INITDIALOG
jne >.WM_DEF ; on last message
; do stuff
jmp    >.EndTab2Proc
.WM_DEF
xor    eax, eax
ret
.EndTab2Proc
mov eax,TRUE
ret

endf



Is this a GoASM thing? Because the original MASM code does not have that 'trap', and it compiles and runs just fine without it.

Code Select Expand

Tab2Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

.if uMsg==WM_INITDIALOG
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret

Tab2Proc endp

[Gunner]

sure it does!!!  else.... mov eax, false tells the dialog handler that you didn't process all other messages

[Shooter]

sure it does!!!  else.... mov eax, false tells the dialog handler that you didn't process all other messages

Not processing all the other messages and not needing to process all the other messages appear to be two different things, to me at least. The original example does not process the WM_DEF message, other than to say 'False', so I'm wondering why I would need to process it in my converted GoASM project any differently. What's the difference between the two different assemblers? Furthermore, what would I need to do when WM_DEF is encountered to make this work?

[ramguru]

everything that starts with dot is a label (the name doesn't matter) .WM_DEF f.e. is like .ELSE .. but the point is:
for all messages that you handle you return 1
and for all that you don't you return 0

[Dogim]

Hi Shooter, i,m not an expert or anything, but here is a working example, it may not be pretty, but it works on my Win7 64 bits box, no overhead on the processor. :bg
i have changed the TCITEM structure, because had some issue with the old one, the newer version seems to work just fine.
http://msdn.microsoft.com/en-us/library/bb760554%28VS.85%29.aspx
ps you should preserve at least edi, i have changed it from eax to edi in the example code.

Code Select Expand

DlgProc frame hWnd,uMsg,wParam,lParam
uses ebx,edi,esi
or
push ebp
mov ebp,esp
push ebx,edi,esi
or