Windows plays foul with tooltips_class32

[jj2007]

Although all params seem to be correct, Windows sets an error 1309, ERROR_NO_IMPERSONATION_TOKEN:

Code Select Expand

invoke SetLastError, 1 ; for testing, set "incorrect function"
invoke CreateWindowEx, WS_EX_TOPMOST, chr$("tooltips_class32"), 0,
WS_POPUP, 0, 0, 0, 0, hWnd, 0, hInstance, 0
xchg eax, edi ; save handle
mov eax, LastError$()
invoke MessageBox, 0, eax, 0, MB_OK ; An attempt has been made ...


The good news is that CreateWindowEx still returns a useful and perfectly working handle. It chokes much later, when I try to use LoadString for a non-existent string:

If the function succeeds, the return value is the number of characters copied into the buffer, not including the terminating null character, or zero if the string resource does not exist. To get extended error information, call GetLastError.

LoadString returns zero, no string. Now guess which error message is reported by GetLastError?

Yeah, "An attempt has been made to operate on an impersonation token by a thread that is not bla bla..."

[xandaz]

   Im not sure this is corrent but should ExStyle be WS_EX_TOOLWINDOW?

[jj2007]

The ex_style apparently plays no role in this. I have tested quite a number of combinations, but cwex always returns that cryptic error. I run Win XP SP2.
I also tested in on my other system (XP SP2), same result.

[dedndave]

i found this - maybe it will help...

http://www.codeproject.com/KB/miscctrl/ballontooltip.aspx

they use

Code Select Expand

WS_POPUP or TTS_BALLOON or TTS_NOPREFIX or TTS_ALWAYSTIP

another possibility is that you aren't wiggling the right bit in InitCommonControlsEx   :P

[xandaz]

  hey jj. The reasone i mentioned WS_EX_TOOLWINDOW was that the other day i was making a tooltip myself and didnt mention that style nor WS_POPUP because the docs say it'll have those styles even if you don't reffer them. The tooltips went all wrong and started appearing in the bottom of the window. Not sure this helps

[jj2007]

  hey jj. The reasone i mentioned WS_EX_TOOLWINDOW was that the other day i was making a tooltip myself and didnt mention that style nor WS_POPUP because the docs say it'll have those styles even if you don't reffer them. The tooltips went all wrong and started appearing in the bottom of the window. Not sure this helps

Yes indeed. MSDN: A tool tip control has the WS_POPUP and WS_EX_TOOLWINDOW  window styles, regardless of whether you specify them when creating the control.

Dave,
I tried (erroneously) the styles you proposed, and the good news is that now GetLastError returns zero==everything fine. Except that cwex retval eax==00, i.e. it also returns no handle :cheekygreen:

[Antariy]

  hey jj. The reasone i mentioned WS_EX_TOOLWINDOW was that the other day i was making a tooltip myself and didnt mention that style nor WS_POPUP because the docs say it'll have those styles even if you don't reffer them. The tooltips went all wrong and started appearing in the bottom of the window. Not sure this helps

Yes indeed. MSDN: A tool tip control has the WS_POPUP and WS_EX_TOOLWINDOW  window styles, regardless of whether you specify them when creating the control.

Dave,
I tried (erroneously) the styles you proposed, and the good news is that now GetLastError returns zero==everything fine. Except that cwex retval eax==00, i.e. it also returns no handle :cheekygreen:

Try to set window position and size of tooltips window as CW_USEDEFAULT in CWEx.

[xandaz]

   That's right antaryi. Look at this jj.

[jj2007]

Try to set window position and size of tooltips window as CW_USEDEFAULT in CWEx.

No effect, same error. But the tooltips work fine anyway; I think it's a kind of internal error. Strictly speaking, if cwex returns a non-zero handle, there is no error. The nuisance is that internally it gets set, and shows up where you don't expect it, i.e. when LoadString returns a zero value and you want to know why. This is not by design, this is a big fat Windows bug.

[dedndave]

this is a big fat Windows bug

i had a gal like that, once   :eek

[oex]

this is a big fat Windows bug

i had a gal like that, once   :eek

:lol No comment

[xandaz]

   Nice oex.

[Antariy]

Strictly speaking, if cwex returns a non-zero handle, there is no error.

Most Win32 functions call SetLastError when they fail. Function failure is typically indicated by a return value error code such as FALSE, NULL, 0xFFFFFFFF, or -1. Some functions call SetLastError under conditions of success; those cases are noted in each function's reference page.

[jj2007]

Alex,

MSDN for CreateWindowEx:

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

CreateWindowEx returns a valid handle but sets this obscure error.

LoadString returns an error (eax=0 bytes, no string found) but does not set lasterror, in conflict with its documentation:

If the function succeeds, the return value is the number of characters copied into the buffer, not including the terminating null character, or zero if the string resource does not exist. To get extended error information, call GetLastError.

IMHO nobody can call that "by design", not even Billieboy.

[Antariy]

Alex,

MSDN for CreateWindowEx: If the function fails, the return value is NULL. To get extended error information, call GetLastError.

This value is set not by CWEx, but anything other call which CWEx does. It meant nothing regardless to CWEx *if* it is returns the handle.