SetWindowLong

typedef already gave me 2 very valuable infos [quote]:

"
Don't know what tooltip you are talking about.
(Possible translation: On a 64-bit system the program does not show tooltips).

and

READ THE FUCKING MANUAL
"

(Unfortunately he did not mention which manual he was referring to.)

Not daring to waste more time of Sir - almost godlike - ASMGURU typedef
here I am.
----------------

My program uses

library kernel,'USER32.DLL'

import user,\
SetWindowLong,'SetWindowLong',\
GetWindowLong,'GetWindowLongA'

invoke SetWindowLong,[btn_hnd1],GWL_WNDPROC,ButtonProc
invoke SetWindowLong,[btn_hnd1],GWL_USERDATA,eax
invoke GetWindowLong,ebx,GWL_USERDATA

to show tooltips.

(Look at the zipfile please)

MS recommends to not use SetWindowLong but SetWindowLongPtr to ensure full compatibility with 64-bit systems.

Because SetWindowLongPtr does not exist in user32.dll, I do not know how to import it.

This problem is well documentated in the net, but mostly for C users.

Seems that I must use a macro ??

My program shows tooltips on 3 different 32-bit computers.

What am I supposed to do ?
Please ...

clamicun,

In Win32 ABI LONG and pointer values are both 32-bit, hence SetWindowLong() can accept pointer to function as its dwNewLong parameter, with proper cast maybe. For Win64 situation is different (pointers are 64-bit there), thus SetWindowLongPtr() have LONG_PTR dwNewLong as its third parameter (that type is said to be big enough to hold either LONG or pointer).

What does it mean for you? That's simple: if you're writing program and it uses Get/SetWindowLong(…, GWL_WNDPROC…) in Win32 version, replace that with Get/SetWindowLongPtr(…, GWLP_WNDPROC…) in Win64 version. You may just add SetWindowLongPtr = SetWindowLong and GWLP_WNDPROC = GWL_WNDPROC somewhere in Win32 includes (perhaps Equates/User32.Inc), then use …LongPtr variation in both cases.

What it doesn't mean? Win32 program, running under 64-bit Windows, doesn't have to detect this and behave any different.

Thank you baldr,
I think, I understand what you say, but..

whereever I put
SetWindowLongPtr = SetWindowLong
GWLP_WNDPROC = GWL_WNDPROC

FASM gives me on:
invoke SetWindowLongPtr,[btn_hnd1],GWLP_WNDPROC,ButtonProc

Error operandsize not specified

Try with equ instead.

Or, alternatively, just forget about SetWindowLongPtr and use only SetWindowLong. There is no difference between them when used in assembly code. It is only to satisfy HLL semantics that SetWindowLongPtr exists.

revolution, thank you too.

It compiles and shows tooltips with equ instead of =

Now I would like to know, if it works on a 64-bit machine.
Seems that we all have to buy a new system in the near future.

Your alternative - not using Ptr - causes not to showup the tooltips on 64-bit

So, I just want to get some details:
1. You made 32-bit application (not 64-bit) with tooltips.
2. You have used SetWindowLong() function.
3. You run it on 32-bit Windows and it shows tooltips properly.
4. You run the same program (same 32-bit EXE from step #1) on x64 and it does not show tooltips properly?

If that is correct - you need to debug the program on x64, just check every
return code from APIs, etc. Something is not right.

AsmGuru62,
that is absolutely correct.

If I understood typedef wright, it does not show tips on his x64.

Does it show tooltips properly on a 32-bit system? It does on mine. (32-bit)

I made changes now - proposed by baldr and revolution.

invoke SetWindowLongPtr

It still runs on mine ,but I have to send it to someone with a 64-bit computer to know,if it works there.

Thank you.

Please let me point out the following:

Here is how your main window procedure begins:

And here is your procedure for a button:

Notice how the 1st procedure "cares" about EBX,ESI,EDI as specified by stdcall convention?
Now notice how the 2nd procedure is missing that part.
Yet, it is also the window procedure, so it must follow the same convention.
EBX is damaged and it MAY cause issues. I am surprised that it works on x32.

Also, what are these strange variables:

You're declaring two DWORDs in each case, but using always only the first one.

P.S. Maybe 'proc' macro cares about esi,edi,ebx automatically? I am not sure... but check it out.

You didn't change anything. The generated binary will have no difference. All you did was tell fasm to use an alias for SetWindowLong.

To AsmGuru62
Thanks, I try to understand this.

The 'strange' variables are for the bitmaps:
It does not work without them.

invoke LoadBitmap,[wc.hInstance],70 ;IDM enc
mov [bmp_hnd1],eax
invoke SendMessage,[btn_hnd1],BM_SETIMAGE,IMAGE_BITMAP,[bmp_hnd1]

Please tell me, if tooltips show up on a 32-bit machine. (If you use one)

To Revolution

Yes -I was thinking exactely the same.
If I set:
GW_is_a_clown equ SetWindowLong

it works.

Thank you.

So here I am again with the latest compilation.

Please ! - someone download the zipfile and test it.
I can not do this on my 32-bit machine.


Thank you all.

I can test it on both x32 and x64 - just got a new Win7 VM at work for a few days!
Just give me few hours:

I see no tooltips on my WinXP SP3 (x32).

#1:


#2:

[quote="AsmGuru62"]I can test it on both x32 and x64 - just got a new Win7 VM at work for a few days!
Just give me few hours:

I see no tooltips on my WinXP SP3 (x32).

Again one of the many miracles. It does show tooltips on my 2 computers
win7 ultimate 32
win 7 prof 32

Here is the version with
invoke InitCommonControlsEx,icex

Thank you very much for your help

It works OK on Win7 x64 Virtual Machine.
So, it works on both x32 and x64 (with a call to InitCommonControls).
I am not sure how I can help.

To AsmGuru62

AsmGuru62,
thank you.
I understood you wright ?

It works?

I ask this because of your last sentence.
(I am not sure how I can help.

Yes -you or someone could help.
It works, but after I clicked a button, I have to hover over another button before the clicked button functions again.
Seems that after clicking , this particulair button looses "communication".
That is not really bad, but I am becoming a bit of a perfectionist.
Have a good weekend over there in Toronto.

This article has useful comments below it:
http://msdn.microsoft.com/en-us/library/bb760256(v=vs.85).aspx

It looks like in XP TOOLINFO structure has one size and AFTER XP ( Vista, Win7, Win8 ) it adds one member and has another size.
That does not explain how it works first and then stops after clicking a button.
You can try to do a custom solution using WM_HOVER message, but that will
require some coding, because you need to do whatever tooltip control does.

guys, why so complicated?

is took me also few hours as I am a total newbee to ASM programming, but was my own christmas gift to learn it.
Thanks to Tomasz's tutorial videos I was able to follow what you guys are talking about. As I also wanted to subclass an edit control, here is the solution which worked fine for me.

in user32.inc there is simply no

GetWindowLongPtrA is there, maybe someone forgot to add it there? or is there a valid reason not beeing in user32.inc?

just add them and all is going good

ps: great forum with a lot of valuable information

kind regards to all asm friends out there.
DJ

The includes that come with fasm are designed to work with Windows 95. So if an API call is defined with a later version of Windows then it isn't included.