en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en de en en en en en nl en en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en en nl en cs en en en en en fr en da en en en en en en en nl en en en pl en en en en en en en en nl en en en en en en en en en en en en en en en en nl vi en en en en en en en en en nl en en en en en en en en en en en fr en da en en en en en en en nl fr en en en en en en en en en en en en en nl en en en en en hbs_lat en en en en en hbs_lat en en en en en en en en en en en en en en en nl en en en en en en en en en en nl en en en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en en nl en en en en en en en lt en en en en en en en nl en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en en en en en nl en en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en en en en en nl de en en en en en en en en en en en nl en en en en en en en en en en fr en da en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for Windows only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
CONTROL ADD ... CALL vs subclassing a control
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
Previous 1 2 template Next
This code shows messages captured by the CALL and Subclass procedures. It would be improved by suppressing all but the first of a series of mousemoves (and probably in 100 other ways) but I ran out of time, any offers?
Last edited by Chris Holbrook; 2 Jan 2008, 06:44 AM. Reason: to insert messages at top of listbox instead of relying on %LBS_SORT
Assuming the documentation is accurate (both PowerBASIC's and Microsoft's), with 'DDT+CONTROL ADD.. CALL' coding you get WM_COMMAND and WM_COMMAND only in the nominated control-level callback procedure; with subclassing you get "all messages."
Meaning of course, if you are interested only in WM_COMMAND for a control, you can use CONTROL ADD...CALL and do have to do anything else; but if you need other messages you have to subclass anyway, so why bother with a CONTROL ADD..CALL since now your 'control specific' code will end up being processed in two separate procedures?
I am also more convinced than ever that this facility was added as a direct response to a "brand M" feature.
In making this post, education mostly.
In offering the CALL extension to CONTROL ADD, I don't know what PB where aiming at. It is also particularly irritating the PBForms doesn't seem to support the feature and cuts of the "CALL..." part whenever you edit the dialog. Maybe I'm missing something.
So, you are basically as mystified as was I?
Well, I think if you come from a 'brand M' environment, it would be attractive to have essentially the same thing as a "Form1_Button1_Click" procedure... and you can't blame PowerBASIC Inc. for attempting to lure brand M users to their product. Heck, I try to lure users of other products to mine, too.
Of course, PB did make the use of this syntax optional so us long-time loyal upgrade-purchasing add-on-products buying customers who started with PowerBASIC for Windows before anyone ever heard of a non-insecticide 'DDT' wouldn't have to change our ways.
Port Washington WI USA
Join Date: Aug 2005
2 Jan 2008, 02:49 PM
Originally posted by Michael Mattias View Post
Knowing very little of the brand, I will take your word for it! But I want to include user-written trigger code in the Forms Designer and it seemed a reasonable place to start, though as you point out the WM_COMMAND messages could be left in the main callback loop. I'm a bit surprised that PB do not offer a packaged form of subclassing as it seems to trip a lot of people up.
Join Date: Jun 2000
2 Jan 2008, 02:59 PM
It's in a *very* rare occasion subclassing controls is required.
It's not even a good method at all.
My tool does not or barely(i just don't recall if..) subclassing controls.
And 2nd, besides some extra message for webbrowser support i never had to enhance the messagepump as well (regarding messages that is).
If you go that direction than imo you mis the point...
Join Date: Aug 2005
2 Jan 2008, 03:02 PM
Would you care to expand on that please Edwin.
Join Date: Aug 1998
2 Jan 2008, 03:10 PM
It's in a *very* rare occasion subclassing controls is required.
It's not even a good method at all.
I could buy into #2 (rare), but it's hardy nonsense or a bad method.
Non-empirically, the number one reason I see a desire for subclassing here is to "Make the   key mark the end of editing and advance to the next data entry field."
I personally don't like this idea (it breaks the "user interface rules" for Windows, because   is used for that purpose), but if this is what you want, subclassing is the only way to get it using standard controls.
Port Washington WI USA
Join Date: Aug 2005
2 Jan 2008, 05:00 PM
Originally posted by Michael Mattias View Post
Non-empirically, the number one reason I see a desire for subclassing here is to "Make the   key mark the end of editing and advance to the next data entry field."
I wonder if Edwin is talking about this approach (from a post of Semen Matusovski's in 2000)?
#Compile Exe #Register None #Dim All #Include "Win32Api.Inc" CallBack Function DlgProc If CbMsg = %WM_DESTROY Then PostQuitMessage 0 End Function Function PbMain() Local Msg As tagMsg, hDlg As Long, i As Long Dialog New 0 ,"", , , 200, 100, %WS_CAPTION Or %WS_SYSMENU To hDlg Control Add TextBox, hDlg, 101, "", 10, 10, 170, 12 Control Add TextBox, hDlg, 102, "", 10, 30, 170, 12 Control Add ComboBox, hDlg, 301,, 10, 65, 170, 100, %CBS_DROPDOWNLIST Or %WS_TABSTOP For i = 1 To 10: ComboBox Add hDlg, 301, "Line"+ Str$(i): Next ComboBox Select hDlg, 301, 1 Dialog Show Modeless hDlg Call DlgProc While GetMessage(Msg, %NULL, 0, 0) If Msg.message = %WM_KEYDOWN And Msg.wparam = 13 Then MsgBox "Hello, Scott" If IsDialogMessage(hDlg, Msg) = %FALSE Then _ TranslateMessage Msg: DispatchMessage Msg Loop MsgBox "Finished" End Function
Join Date: Jun 2000
2 Jan 2008, 05:09 PM
Well it's a long story and i am going zzz..
Superclassing is fine, subclassing is not.
So if you need some handling on enter, use a superclassed control or simply make it work in the windowproc() itself.
Any oddity in the messagepump will be working for modeless windows as well.
So you can introduce unwanted behaviour for modeless windows.
And maybe even for ordinary childcontrols.
My rule of thumb is to keep it as straight forward as it is unless you will have control over it.
Preparing functionality for others like in the form of a dll or whatever is: not having control over the situation.
Subclassing, o boy, what was the correct previous callback procedure on unhook..?
Imagne multiple hooks on the same control.
My rule of thumb is
1) if you do subclassing, you may consider not to restore.
2) Creating a control on a form and a dll is subclassing the control, who guarantees a good restore on dll unload etc?
It's not that you can't..
Usually hooks are not required anyway.
Join Date: Aug 2005
2 Jan 2008, 05:32 PM
Thanks Edwin, I'm learning here.
Join Date: Aug 1998
2 Jan 2008, 05:59 PM
> Creating a control on a form and a dll is subclassing the control
It is? Since when? AFAIK subclassing requires a call to SetWindowLong.
> who guarantees a good restore on dll unload etc?
The programmer should never free a library which is in use. This is programming 101. Well, maybe Programming 102.
UNLESS.. are these some weird things 'brand M' does unbeknownst to the programmer? (I don't do brand M).
Port Washington WI USA
Join Date: Jun 2000
2 Jan 2008, 11:05 PM
I justed wanted to point out that subclassing is the lesser choice.
I am not the best person to explain these things, i am against subclassing unless there is no alternative.
So far it's been proven to me that there is no or very little need for control hooks.
Join Date: Aug 2002
3 Jan 2008, 12:19 AM
Do you program more in DDT style programming or SDK?
I don't have much experience in SDK style programming, but have found subclassing is about the absolute best choice for quick and easy behavior modifications to controls when programming in DDT.
For a simple enter key modification to a single textbox, it just seems a bit much to create a superclass of the control and then add to the window/dialog.
Join Date: Jun 2000
3 Jan 2008, 02:31 AM
#1, I almost never use PBEdit but my own tool, it nearly fades out the difference between DDT and SDK
#2, subclassing is often used due lack of knowledge.
One of the things helped me understanding Windowsbehaviour is using some tool which translates messages sent to the windowprocedure of the parentwindow (your DDT form) to readable text.
Case %WM_COMMAND Select Case nCbCtl Case %IDOK Select Case nCbCtlMsg Case %BN_CLICKED If GetFocus() = GetDlgItem( CbHndl, %ID_FORM1_TEXT1 ) Then MsgBox "Enter pressed", %MB_TASKMODAL End If End Select Case %IDCANCEL Select Case nCbCtlMsg Case %BN_CLICKED ' User hits escape End Select End Select Case %WM_NOTIFY
For specific key features you may indeed consider a superclassed edit control.
A hook is fine if you don't have other options, there are better methods usually though.
Join Date: Aug 2005
3 Jan 2008, 03:20 AM
Subclass / CONTROL CALL eg redone sans subclassing
Having done this does not give me any strong feelings about subclassing vs message pump approach, at this level they involve similar amounts of labour and result in code of similar complexity!
#COMPILE EXE #REGISTER NONE #DIM ALL #INCLUDE "Win32Api.Inc" %IDD_DIALOG1 = 101 %IDC_LABEL1 = 1001 %IDC_BUTTON1 = 1003 %IDC_LISTBOX1 = 1010 %IDC_LABEL4 = 1012 %IDC_LINE1 = 1013 '-------------------------------------------------------------------------- CALLBACK FUNCTION DlgProc LOCAL sz AS ASCIZ * 64 LOCAL lcbctlmsg AS LONG SELECT CASE AS LONG CBMSG CASE %WM_INITDIALOG REDIM tbs(0 TO 2) AS LONG 'Note: negative values makes tabs stops right aligned, ' positive values makes them left aligned tbs(0) = -50 : tbs(1) = -100 : tbs(2) = -210 CONTROL SEND CBHNDL, %IDC_LISTBOX1, %LB_SETTABSTOPS, UBOUND(tbs)+1, VARPTR(tbs(0)) CASE %WM_COMMAND 'lcbctlmsg = HI(WORD, msg.wParam) IF LO(WORD, CBWPARAM) = %IDC_LABEL1 THEN lcbctlmsg = HI(WORD,CBWPARAM) SELECT CASE lcbctlmsg CASE %STN_CLICKED sz = "STN_CLICKED" CASE %STN_DBLCLK sz = "STN_DBLCLK" CASE %STN_DISABLE sz = "STN_DISABLE" CASE %STN_ENABLE sz = "STN_ENABLE" END SELECT sz = "DIALOG" + $TAB + sz + $TAB + "LABEL1" CONTROL SEND CBHNDL, %IDC_LISTBOX1, %lb_insertstring, 0, VARPTR(sz) END IF CASE %WM_DESTROY PostQuitMessage 0 END SELECT END FUNCTION '-------------------------------------------------------------------------- FUNCTION PBMAIN() LOCAL Msg AS tagMsg, hDlg AS LONG, i AS LONG LOCAL sz AS ASCIZ * 64 LOCAL hLABEL1 AS LONG ' window handle to LABEL1 control LOCAL hBUTTON1 AS LONG ' window handle to BUTTON1 control LOCAL lcbctlmsg AS LONG DIALOG NEW 0 ,"DDT LABEL TRIGGERS", 7, 62, 408, 161, %WS_CAPTION OR %WS_SYSMENU TO hDlg CONTROL ADD LABEL, hDlg, %IDC_LABEL1, "Label1", 30, 35, 85, 20, %WS_CHILD OR %WS_VISIBLE OR %SS_LEFT OR %SS_NOTIFY OR _ %SS_SUNKEN OR %SS_NOTIFY, %WS_EX_LEFT OR %WS_EX_LTRREADING CONTROL ADD BUTTON, hDlg, %IDC_BUTTON1, "Press me to disable LABEL1", 10, 60, 125, 15 CONTROL ADD LISTBOX, hDlg, %IDC_LISTBOX1, , 155, 20, 240, 130, %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP OR %WS_VSCROLL OR _ %LBS_MULTIPLESEL OR %LBS_SORT OR %LBS_NOTIFY OR %LBS_USETABSTOPS, %WS_EX_CLIENTEDGE OR %WS_EX_LEFT OR %WS_EX_LTRREADING _ OR %WS_EX_RIGHTSCROLLBAR CONTROL ADD LABEL, hDlg, %IDC_LABEL4, "Control and message id", 155, 5, 240, 15 CONTROL ADD LINE, hDlg, %IDC_LINE1, "Line1", 5, 25, 135, 55 CONTROL HANDLE hdlg, %IDC_LABEL1 TO hLABEL1 CONTROL HANDLE hdlg, %IDC_BUTTON1 TO hBUTTON1 DIALOG SHOW MODELESS hDlg CALL DlgProc WHILE GetMessage(Msg, %NULL, 0, 0) ' DIALOG SET TEXT hdlg, "d="+STR$(hdlg) + " c=" + STR$(hLABEL1)+ " b=" + STR$(hBUTTON1) ' sz = ""'"hW="+str$(msg.hWnd) + "L=" + str$( LO(WORD, msg.lparam)) + ":" + str$(HI(WORD, msg.lparam)) _ ' '+ ": W=" + STr$(LO(WORD, msg.wparam)) + ":" + str$(HI(WORD, msg.wparam)) SELECT CASE msg.hwnd CASE hLABEL1 SELECT CASE msg.message CASE %WM_MOUSEMOVE sz = "WM_MOUSEMOVE" CASE %WM_RBUTTONDOWN sz = "WM_RBUTTONDOWN" CASE %WM_LBUTTONDOWN sz = "WM_LBUTTONDOWN" CASE %WM_LBUTTONDBLCLK sz = "WM_LBUTTONDBLCLK" END SELECT sz = "LABEL1 " + $TAB + sz CASE hBUTTON1 sz = "" SELECT CASE msg.message CASE %WM_LBUTTONDOWN sz = sz + $TAB + "WM_LBUTTONDOWN" IF IsWindowEnabled(hLABEL1) THEN CONTROL DISABLE hDlg, %Idc_LABEL1 CONTROL SET TEXT hDlg, %IDC_BUTTON1, "Press me to enable LABEL1" ELSE CONTROL ENABLE hDlg, %Idc_LABEL1 CONTROL SET TEXT hDlg, %IDC_BUTTON1, "Press me to disable LABEL1" END IF END SELECT IF sz   "" THEN sz = "BUTTON1" + $TAB + sz END SELECT IF TRIM$(sz)   "" THEN CONTROL SEND hDlg, %IDC_LISTBOX1, %lb_insertstring, 0, VARPTR(sz) IF IsDialogMessage(hDlg, Msg) = %FALSE THEN TranslateMessage Msg DispatchMessage Msg END IF LOOP END FUNCTION
Join Date: Aug 1998
3 Jan 2008, 08:39 AM
> from a post of Semen Matusovski's in 2000
Well, Mr. Matusovki has proven to me he's an excellent programmer, but from a 'technique' standpoint I find this code inferior.
It mixes 'DDT' with SDK coding. Not invalid or illegal or unsupported, but it's always been one of my 'rules' that "Thou Shalt Not Mix DDT and SDK syntax except when there is no other option."
I don't like messing with the primary thread's message loop. Coming from the Dark Ages Before There Was Such a Thing As DDT, I like a 'clean' message loop and much prefer to handle dialog/window/control-specific code in the window procedure to which it applies.
Port Washington WI USA
Join Date: Aug 2005
3 Jan 2008, 02:50 PM
Originally posted by Michael Mattias View Post
> ...it's always been one of my 'rules' that "Thou Shalt Not Mix DDT and SDK syntax except when there is no other option."
Originally posted by Michael Mattias View Post
> I don't like messing with the primary thread's message loop
That's a vote for subclassing then.
I don't have enough experience to have much of an opinion on SDK/DDT/bit of both - yet!
Join Date: Jun 2000
3 Jan 2008, 03:55 PM
>That's a vote for subclassing then.
Yes, using an alternative messagepump is imo even worse.
Join Date: Aug 1998
3 Jan 2008, 04:50 PM
>> ...it's always been one of my 'rules' that "Thou Shalt Not Mix DDT and SDK syntax >>except when there is no other option."
It is totally and absolutely subjective, biased and non-empirical. (i.e., it "feels" like a good rule to follow).
Except: For sure you may not use "DDT" commands on windows or controls created with other than DIALOG NEW/CONTROL ADD, or against a handle for a window/control for which the DIALOG NEW was executed from another code module.
Note that some DDT commands "may" "work"... that is, they will "work" with this version of the compiler and this version of the operating system, but could break when either changes.
Port Washington WI USA
Previous 1 2 template Next
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 10:47 PM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.