The MASM Forum Archive 2004 to 2012

    I've been working on this example for an Extra Controls Library and got this made for now. I feel kinda happy though maybe the code seems a bit dirty. Just wanted to get it to work.
    Enjoy

    well... There are some things that need fixing.
    i'll post later.

   I think i might need some help... Can someone look at it? Why doesn't DrawText draw the text when i send STXM_ADDCONTENT and the Static Control is visible?

What I've found after a quick view:
STXM_ADDCONTENT:
        invoke  SendMessage,hWnd,WM_PAINT,0,0              ; <- make no sense - do not send WM_PAINT explecit -> InvalidRect()
        invoke  InvalidateRect,hWnd,addr [esi].rect,TRUE   ; <- is RECT properly filled?

WM_PAINT:
            invoke  ShowWindow,hWnd,SW_SHOW                     ; WM_PAINT is for painting!
            invoke  ShowWindow,[esi].ChevStruct.hCh,SW_HIDE     ;
            invoke  SetTimer,hWnd,0100,2000,addr StaticExProc   ;
            ...


    lmao q. I've tried InvalidateRect at first but it didn't work out. So, ... i'll remove that nonsense and report later. Thanks Q.

if you want to update the window immediately, follow the InvalidateRect with UpdateWindow
also - you can use InvalidateRgn with the handle of the static control and NULL for hRgn
it's probably easier than InvalidateRect because you don't need a RECT

   I'm getting pretty tired of this control. I've fixed all that nonsense although some tihngs might be overlooked. I'm having some trouble finding why i can't process the STXN_HEIGHTCHANGED notify message.
   Q... i was trying a lot of things and left some functions lying around that's why those WM_PAINT and InvalidateRect were together. Also i had tried InvalidateRect and it wasn't working somehow and i tried the PAINT. This new zip is more acoording to the publics liking. It just doesn't resize the list view control. I'm tired and need sometime to freshen up my ideas. It's one of those obvious mistakes i'm making but i always fail to see the obvious.
   Thanks for all the help guys.

hi,
maybe I will step in the next days. However, you may read in the good old win32.hlp or at msdn about windows and painting/drawing (http://msdn.microsoft.com/en-us/library/dd162759(v=vs.85).aspx). Also I've seen, that there is still a SetTimer() in you WM_PAINT-handler.

BTW: there is a nice trick in you code:
        push    hInstance
        pop     wcStaticEx.hInstance
        sub     esp,4
        pop     wcChevron.hInstance :dance:

        mov     eax,hInstance
        mov     wcStaticEx.hInstance,eax
        mov     wcChevron.hInstance,eax

Quote from: dedndave on February 06, 2012, 01:28:00 AM

Code Select Expand

        mov     eax,hInstance
        mov     wcStaticEx.hInstance,eax
        mov     wcChevron.hInstance,eax

4 bytes shorter, and probably 1 or 2 nanoseconds faster :bg
But the sub esp, 4 trick is cute anyway :thumbu

hi,
after some modification, it seems to work for me - but I'm not sure, if the result is what you expect.

Some points/hint about your code:
o  you are always using + to combine flags -> OR
o  SetTimer() is used incorrect -> SetTimer(hWnd,ID,0)
o  GDI:
        obj = SelectObject(hDC,CreateWhatEverGDI_Obj());
        draw/paint
        DeleteObject(SelectObject(hDC,obj));       
o typing error?: && used for testing a bit/flag -> &
o SHGetFileInfo: SHGFI_ICON is missing
o it seems like the used RECT-structures are not proper  filled -> this was/is a problem when using them with InvalidRect()
o hint: fill API structures before the call, thus the code is quickly comprehensible (e.g. FillListView)
o hint: create copies off all data/object that your control receives: alloc()+szCopy() , CopyIcon() , ...
        This makes clear who owns the object and also avoids usage of invalid handles/pointers.
        Of course this is not practical for memory consuming stuff like huge bitmaps.
o hint: use INT3 to test if a specific path is execute

in the attachment the code. For convenience I've merged the source files

Hi qWord,

The exe in your attachment won't start on XP - access denied. Reassembling helps, though. Attached both versions.

hi,

Quote from: jj2007 on February 06, 2012, 12:43:27 PMThe exe in your attachment won't start on XP - access denied. Reassembling helps, though. Attached both versions.

so it requires adminstator rights for reading C:\ ?

i had a similar problem with qWord's network time program
i got the "not a valid wn32 application error" - re-assembling fised it
i am guessing it may be a problem with the libs

Quote from: dedndave on February 06, 2012, 01:12:11 PMi am guessing it may be a problem with the libs

Currently I think it is a problem of the linker: I'm using link.exe, v11 ...
jj, can you test attached EXEs?

qWord

Quote from: qWord on February 06, 2012, 01:00:24 PM
so it requires adminstator rights for reading C:\ ?

No, I have full rights here, I can even create files in C:\WINDOWS\system32\*
By the way: why should it read from C: if my Masm32 installation is on D:??
As Dave wrote, the error is "not a valid Win32 application". Only the xl11 app shows this behaviour, the others work fine.

Quote from: jj2007 on February 06, 2012, 01:26:37 PMOnly the xl11 app shows this behaviour, the others work fine.

thx - seems link.exe version 11.00.40825.2 produce incompatible/invalid EXEs ...

you are correct, qWord

(http://www.masm32.com/board/index.php?action=dlattach;topic=18259.0;id=10285)

the other 2 apps work ok under XP MCE SP3

there may be a linker v11 command-line switch that makes compatible PE files   :P

there is a second possibility: the PE loader of XPSP3 is buggy  :bg

that's funny:  the only difference bettween the EXEs created by link v10 and v11 are 10 byte in the DOS-Header (offset 0x80-0x89)

Quote from: qWord on February 06, 2012, 02:21:00 PM
that's funny:  the only difference bettween the EXEs created by link v10 and v11 are 10 byte in the DOS-Header (offset 0x80-0x89)

There are some more. What prevents it from running is IMAGE_OPTIONAL_HEADER Major subsystem version, 2 bytes at 100h.

   Hi guys... How about the STXN_HEIGHTCHANGED? Can anyone see why it doesn't get to the main window proc? Or does it and i'm (as usually) overlooking some details?
   Thanks.
   Nice JJ. I rarely think of moving data into a register unless m2m. I guess i should keep that in mind. ASM is supposed to be higinic.
   Later

Quote from: xandaz on February 06, 2012, 04:31:38 PMHi guys... How about the STXN_HEIGHTCHANGED? Can anyone see why it doesn't get to the main window proc?

in the WM_TIMER-handler:
            invoke GetParent,hWnd
            mov edx,eax
            invoke  SendMessage,edx,WM_NOTIFY,0,addr stxnsc

Quote from: jj2007 on February 06, 2012, 03:07:36 PMWhat prevents it from running is IMAGE_OPTIONAL_HEADER Major subsystem version, 2 bytes at 100h.

yep, that's it.

   Q? Why
mov edx,eax
!i SendMessage,edx,...
    That doesnt work either.... am i misinterpreting something? It's a bit hard for me to understand english when it's spoken by natives.

Oh it's
GetParent,hWnd
and not
GetWindow,....
Sorry. My mistake. Yep.... INVALID_WINDOW_HANDLE.Thanks

    I'm having a hard time understanding why the hWndParent member is not valid when i send the STXN_HC. The first version i made works fine now i have to get the parent's window handle. Why is that?

    It was kinda hard but it worked out. Yeah Q, the rects what not correctly filled. The Rectangle is not in client coordinates. I'm sure that someone might find it useful. How didnt i know that already?
    Also in the Chevproc edi was pointing to the wrong structure and that's why i could use the handle to send the STXN_ADDCONTENT.
    Well, thanks a lot guys for your pacience.
    Latest version following....

    Hi guys... i moved a little further and decided to add an explorer control to the Extra Controls Lib. I came across a little problem. The messages from the child controls of the EXPLORER class windows dont message to the main proc. Can this be done without subclassing? If these child controls were children to the main winow, the main winowProc would recieve the messages. Why not so in this case?

Child windows sends their notifications only to the parent window. If the messsages are needed by the grandparent, simply redirect them in your ExplorerProc  as needed.

    Have you looked into the example? The parent windows isn't getting the WM_MOUSEMOVE from the two child controls.

WM_MOUSEMOVE is only sent to the window that has the cursor over it
if the cursor is over a child, it is only sent to that child, etc
if you capture the mouse with SetCapture, then things are different

    yeah dave. It seems it only sends the parent window a limited range of messages. Meaningly those that are useful. Subclassed it and it works. but i came across more problems to solve. Thanks