SysTabControl and click event

[norbert doerre]

From the sight of a called DLL, I 'injected' a combobox and some other controls temporarily into a systabcontrol of it's calling EXE. All Dialog processes are done by the DLL code. The DLL also contains the dialog itself with all it's controls. It is not a good idea to program all eventualities of possible DLL content inside the EXE code. Therefore I reserved the tab area for access by various DLLs to enable the user to configure their functionality always at the same place in the user interface.
For PB, I could not find an enumeration of a systabcontrol. So there remains one indifferent kink in the code:
I can set and get the current tab, but I cannot exactly get the click event of a tab. After another tab is clicked, WPARAM, LPARAM contain always the same sequence of three number pairs:

0, 1309144
0, 1308132
0, 1308132

I have to use the click event because after changing to another tab in a systabcontrol the last used tab area hWnd always changes to make it's content invisible. So, getting back to the last opened tab, the dialog content is lost.
It would be simple to regenerate the dialog by always reloading it by the DLL after a click on the desired tab.
Systab enumerations found in WWW mostly rely on .NET programming and are not very useful.

[Michael Mattias]

or PB, I could not find an enumeration of a systabcontrol. So there remains one indifferent kink in the code:
I can set and get the current tab, but I cannot exactly get the click event of a tab.

Enumerate a SysTabControl? This has got to be a language thing: there is nothing to enumerate. You can get a count of tabs, or enumerate any child windows the tab control happens to have but there is nothing intrinsic to the tab control to 'enumerate.'

"Click events" on tab controls can be detected by intercepting WM_NOTIFY/NM_CLICK notification messages. (Although I suspect you'd rather intercept WM_NOTIFY/TCN_SELCHANGE since you probably don't care if the user clicks on the tab item which is already the selected tab).

FWIW, when I use tab controls I store a handle to the associated window as the tab item's "lparam" in the TCITEM structure for that item. Makes it real easy to know which windows to hide/show on TCN_SELCHANGE notification.

MCM

[norbert doerre]

This is what I could test in the mean time with SysTabControls. I translated most of the comments to English. This is the first part of extractions from my code trying out the TCM_ constant list.
Michael, the proposals You made were not useful in my case. But with the code I'm sending I can do all I currently need. Perhaps others are interested, too to accomplish working with the TCM_ constants. I think I have them all but don't know if they could be published here.

hSettingsDlg = FindWindow("#32770", "MechaniCAD Einrichtung")
'In the Exe, I gave each SysTab page a name to find them easily by DLL code.
'hTab is the handle of one Tab area. Save it for reload by stepping back.
hTab = FindWindowEx(lRet, 0, "SysTabControl32", "TxtAtbTab")
'Extended Style Tool Window
lRet = SetWindowLong(hWnd, %GWL_EXSTYLE, %WS_EX_TOOLWINDOW)
'SysTab Items Handle (same for all)
hSysTab = FindWindowEx(hSettingsDlg, 0, "SysTabControl32", "") 'Handle der SysTab-Reiterschaltflächen
If hSysTab Then ... 'following Is simply an enumeration Of some tested code	
lTabIndex = 4
	'Open Tab with Index
	lRes = SendMessage(hSysTab, %TCM_SETCURFOCUS, lTabIndex, 0) 'HchFillTab Table öffnen
		
	'Current open Tab
	Control Send hSettingsDlg , 0, %TCM_GETCURSEL, 0, 0 To lRes 'Testen, welches Tab geöffnet ist.
		
	'Tab Count
	lRet = SendMessage(hTab, %TCM_GETITEMCOUNT, 0, ByVal 0)
		
	'Tab Delete
	lRet = SendMessage(hTab, %TCM_DELETEITEM, lRet - 1, ByVal 0)
		
	End If

'Following could be interesting, too. But I could not yet reference it:

'%EM_SETIMESTATUS = &HD8 = 216
'%VK_ICO_00             = &HE4 = 228
'%VK_OEM_BACKTAB   = &HF5 = 245
'%VK_EREOF              = &HF9 = 249

'Chars generated by Tab Click in DefWindowProc:
'			wParam:		     lParam:		
'			LO     HI              LO       HI
'			0	0	        216 	249
'			0	0		228	245
'			0	0		228	245

I cound not find here anything else.

[Michael Mattias]

Michael, the proposals You made were not useful in my case

???

So what were you looking for?

You asked for...

For PB, I could not find an enumeration of a systabcontrol.

I addressed this: there is no such thing.

...but I cannot exactly get the click event of a tab

I addressed this, too. (WM_NOTIFY/ either NM_CLICK or TCN_SELCHANGE notification message).

Perhaps others are interested, too to accomplish working with the TCM_ constants.

There are already several good examples of working with tab controls in the source code forum. Of course, you are welcome to add an additional demo if you feel it will benefit someone.

[norbert doerre]

Michael,
I did not mean that Your comments are not useful at all. I mean that they are not _in my case_. The reason is that i cannot get other 'onclick' messages than the ones i attached at the end of my last message.
Adding a systabcontrol to a dialog and using it is quite simple and needs not further to be published. But resolving it backwards from an exe is quite a different thing even if you programmed it yourself. This is what I think to be interesting - at least for me.
Perhaps you are able to discuss the values i could receive.

[Michael Mattias]

I'm sorry, I simply cannot understand what it is you want to do. I would try to help if could.

[norbert doerre]

Well, all is running now.

I had to process the main mdi frame window of my exe with:
gHookWnd = GetWndFrame() 'global handle of the MDI frame

I created the process Function:
FrameWindowProc = SetWindowLong(gHookWnd, %GWL_WNDPROC, CodePtr(DefWindowProc))

Then, i used:
Function DefWindowProc(ByVal hWnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

Select Case lParam
If lParam = 1308132 Then 'lParam = 1308132: SystabControl was switched
UseHchLay(0, 0) 'Standard routine to handle building and messaging of
a frameless dialog, inserted in a Tab area of the main
EXE during runtime, dynamically created by a DLL.
The frameless dialog can be placed on a tool systab
area.
End If
End Select

End Function

This way, i managed creating dynamically an additional tab area inside the EXE main program interface via DLL. But still, I don't exactly know the background of the lParam value '1308132' telling that the systab part of the systabcontrol was switched. I tested it on several PCs without failure, but I don't know if the lParam value differs from SysTabControl implementation to SysTabControl implementation.
Background:
Large applications with many DLLs offer DLL contents as tools. To configure each tool you normally need an additional dialog on screen. This hinders the user from having a good overview over graphical contents. This method concentrates all DLL tool settings to one single dynamically changing systab, the same for all DLLs. The best of all: I need no more editing the EXE for this purpose.

[Michael Mattias]

There is no way testing lparam for '1308132' in a window procedure before testing wMSG can work.

None.

Zero.

If it is "working" it is pure unmitigated luck. What lparam means always depends on uMSG, and since you are not testing uMSG first....


For that matter I don't even know how you got a function named "DefWindowProc" to compile, since that function is DECLAREd in Win32API.INC (it's in USER32.DLL). Unless you're not using Win32API.INC but we wouldn't know that since insufficient code is posted.

(Except... didn't compilers prior to 8x - erroneously - allow duplicate symbols like this as long as the ALIASes were different? I'm pretty sure they did, but I forgot which one it decides to use). (But we don't know what version of compiler you're using, so that may not be relevant at all).

MCM

[norbert doerre]

Isn't that funny???
After i found out that uMsg always contains 70 after a click i was shure i found it. I always test uMsg separately from wParam and lParam.
(uMsg = 70, lParam = 1308132) This is a reliable result of tab change. I tested it on four PCs in my office. - Above all, it runs even with virtual "Wine"! - Even better with real wine!
In fact, I used - just for an experiment - "DefWindowProc", the standard API process name, as function name, and it runs. Try it!
(PB compiler seems to compile nearly everything. )

[Michael Mattias]

>I always test uMsg separately from wParam and lParam.

You did not do that in the code you posted above.

If you want help with code, you have to post the actual code, not something you make up on the fly.

After i found out that uMsg always contains 70 after a click i was shure i found it.

It should equal 78 (decimal)

' Win32API.INC
...
%WM_NOTIFY                     = &H4E

(uMsg = 70, lParam = 1308132) .....
This is a reliable result of tab change

No, it is not.

Use the code I wrote for you in the other thread. That IS reliable.

[Kev Peel]

Naming a function DefWindowProc only works because you are (in a way) tricking the compiler into thinking the declared DefWindowProc (the one in win32api.inc) is referencing your function.

Now you could keep your function called DefWindowProc, but what if you need to call the API's DefWindowProc? You won't be able to since the compiler thinks you mean you want to call your function.

My advice to anyone reading this is do not name functions after Windows declared API functions. It is simply asking for trouble, and surely using descriptive name such as dlgProc_ForDialogThatDoesAction would help in reading the code in the future.

[Michael Mattias]

I think that duplicate procedure name with different ALIAS DECLARE thing was fixed in 8 point oh something. (It's not allowed, which is correct).

[norbert doerre]

Sorry, but I hate hex codes. In the mid sixties i worked as a student and had to calculate hex codes w/o electronic calculator....they were not yet available.

Code 78 dec is never thrown out during runtime of the dll, but codes 80 and 81. Code 80 signals that tab selchange has completed, code 81 signals that tab selchange is about to start.

[Michael Mattias]

>Code 78 dec is never thrown out during runtime of the dll, but codes 80 and 81.

Eighty and Eight-one decimal?

I have no idea what "code" you are looking at.

They ain't tab control notifications, which are all in the range -550d to -580d (%TCN_FIRST to %TCN_LAST)

And if they are WM_xxx messages they would be..

%WM_INPUTLANGUAGECHANGEREQUEST = &H50
%WM_INPUTLANGCHANGEREQUEST     = &H50
%WM_INPUTLANGUAGECHANGE        = &H51
%WM_INPUTLANGCHANGE            = &H51

.. which don't have a hell of lot to do with tab controls.

MCM