What subclassing was changed...I'm not seeing anything different...it still checks for FF_PTR on all controls and you didn't take out the code that only applies OPAQUE to Multiline boxes...my generated code is still-
Case %WM_CTLCOLOREDIT, %WM_CTLCOLORLISTBOX, %WM_CTLCOLORSTATIC, %WM_CTLCOLORBTN
'Message received from child control about to display.
'Set the Color properties here.
'lParam is the handle of the Control. wParam is the hDC.
FF_hDC = wParam
ff_control = GetProp(lParam, "FF_PTR")
If ff_control = 0 Then Exit Select 'let the DefWindowProc handle the coloring
If @ff_control.ProcessCtlColor Then
SetTextColor FF_hDC, @ff_control.hForeColor
If @ff_control.IsBackSysColor Then
SetBkColor FF_hDC, GetSysColor( @ff_control.BackColorNumber )
Else
SetBkColor FF_hDC, @ff_control.BackColorNumber
End If
SetBkMode FF_hDC, %TRANSPARENT
'If this is a TextBox then we must use the %OPAQUE style, otherwise
'we will get a lot of screen garbage in the control when scrolling.
GetClassName @ff_control.hWndControl, FF_zTempString, SizeOf(FF_zTempString)
If UCase$(FF_zTempString) = "EDIT" Then
If (GetWindowLong( @ff_control.hWndControl, %GWL_STYLE) And %ES_MULTILINE) Then
SetBkMode FF_hDC, %OPAQUE
End If
Else
End If
'Return the handle of the brush used to paint the background
Function = @ff_control.hBackBrush
Exit Function
End If
End Select
Change this to code below to allow for Colored dropdowns and fix the text box draw problem:
Case %WM_CTLCOLOREDIT, %WM_CTLCOLORLISTBOX, %WM_CTLCOLORSTATIC, %WM_CTLCOLORBTN
'Message received from child control about to display.
'Set the Color properties here.
'lParam is the handle of the Control. wParam is the hDC.
FF_hDC = wParam
ff_control = GetProp(lParam, "FF_PTR")
If ff_control = 0 Then
ff_control = GetProp(GetFocus(), "FF_PTR") ' Get ComboList's Parent that has Focus
If ff_control = 0 Then Exit Select 'let the DefWindowProc handle the coloring
End If
If @ff_control.ProcessCtlColor Then
SetTextColor FF_hDC, @ff_control.hForeColor
If @ff_control.IsBackSysColor Then
SetBkColor FF_hDC, GetSysColor( @ff_control.BackColorNumber )
Else
SetBkColor FF_hDC, @ff_control.BackColorNumber
End If
'If this is a TextBox then we must use the %OPAQUE style, otherwise
'we will get a lot of screen garbage in the control when scrolling.
GetClassName @ff_control.hWndControl, FF_zTempString, SizeOf(FF_zTempString)
If UCase$(FF_zTempString) = "EDIT" Then SetBkMode FF_hDC, %OPAQUE Else SetBkMode FF_hDC, %TRANSPARENT
'Return the handle of the brush used to paint the background
Function = @ff_control.hBackBrush
Exit Function
End If
End Select
Hi Roger,
Right you are... I uploaded the wrong FFengine.exe. I re-uploaded the correct files. Give it a shot and let me know if it suits your needs.
Nope, generates the exact same code...
Yes, it still appears that the package on the website is not correct. Must have been a problem when I ftp'd it up yesterday. I will upload the correct package as soon as I can.
Hi Roger,
I re-uploaded the zip file with all of the files. Unzip and preserver directory structure. Overwrite your existing files. (the zip file does not contain the installation program - it is simply the FireFly files themselves).
Perfect, appears to have fixed everything. Changed my menus and statusbars, so I can't test the weird loading it was doing on those where I'd have to click each to reload and get the checks and stuff to init...but everything else is there.
Added:
Actually checking the resource file, it still appears not to store my default checks till clicking on the menu bar then clicking Ok on the dialog.
Now that we took care of everything...what Combobox subclassing was removed/commented out? And, you might also add to the list of new stuff that Combos now have colors in the listbox/dropdown that properly match that of what the user selects for the combo...one cool plus I really like and am glad I came up with. :P
Only found one problem so far with new combo colors...only effects Simple Combos since their Listbox is showing all the time. No big deal since they are about the most useless of the combos with their Edit box being clumsy and they are just plain ugly...
Appears they are a special case since the others have a listbox on the fly and the only ones with a child is the Dropdown since it has an Edit box always showing (Weird how it paints fine like its Hwnd is linked with the Combo) and Simple with both an Editbox and Listbox always showing. So a test for a ClassName of ComboLBox should do the trick AFTER the test for the Control with focus (Since I believe that is the classname of the on the fly ones too. Might even want to test the GetFocus Hwnd and make sure it is a ComboBox class so another control's colors aren't used to paint the listbox of the Simple when another control has focus during CREATE), so GetFocus's FF_PTR, ELSE GetParent's FF_PTR and then if neither then break out and let WinProc do its thing. If I just totally blew your mind throwing all that at you, I'll toss some code together when I'm on my other PC tomorrow.
Could be whatever code you had to comment out for GPFs, etc didn't account for the weird child/on-the-fly controls of Combos too.
Hi Roger,
I decided not to comment out the subclass code for the edit portion of the combo box. Instead, I decided to add code that only subclasses the edit portion on operating systems higher than Win98 (eg. Win2K, WinXP).
:)
If there are features that you can implement only for the newer operating systems I say do it. It someone wants to program for old operating systems they can use old versions of FireFly. Thank God that DOS is gone; Windows 98 should be forgotten too, in my opinion. When your lunch costs more than your computer is worth, it is time to upgrade.
Look forward, move ahead, get straight. Maybe this should go to the FireFly 3.0 sticky.
I found the code you mentioned about subclassing, and it could very well be related since not all combos have an Edit portion...plus I found that you still do something with OldCBProc no matter what in DESTROY. This could be why the Edit portions paint right and the listboxes don't too since they are subclassed...so what was the reason behind the subclassing? Are they handling some type of keystrokes? Might need to add code like the paint code for listboxes in whatever section the edit portion is needed to check for the class of the edit and/or the class/style of the parent/combo, etc.
Also, in the control code proc, how does "If hWndControl Then ff = GetProp(hWndControl, "FF_PTR")" prevent it from handling controls not created by FF...like the Edit/Listboxes...I see a couple checks here and there, but why not do away with the checks and if no ff, then exit function and call defproc.
Isn't .OldProc = 0 possibly causing problems too since the edit is subclassed, but this is set to 0 which is then called in the CODE PROC since there is no check for 0 before calling it?
Found an error in the TagProperty cleanup code and a few optimizing items:
Case %WM_DESTROY
'Unsublass the Control
If ff Then
'Delete the fonts/brushes used for this Control
If @ff.hBackBrush Then Call DeleteObject(@ff.hBackBrush)
If @ff.hFont Then Call DeleteObject(@ff.hFont)
FF_ProcAddress = @ff.OldProc
'Re-claim the memory used by the type structure
Call HeapFree(GetProcessHeap(), 0, ByVal RemoveProp(hWndControl, "FF_PTR"))
'Remove the property holding the Tag property string.
FF_tempLong = GetProp(hWndControl, "FF_TAGPROPERTY")
If FF_tempLong Then Call HeapFree(GetProcessHeap(), 0, ByVal RemoveProp(hWndControl, "FF_TAGPROPERTY"))
'Allow the WM_DESTROY message to be processed by the control.
SetWindowLong hWndControl, %GWL_WNDPROC, FF_ProcAddress
CallWindowProc FF_ProcAddress, hWndControl, wMsg, wParam, lParam
End If
Function = 0: Exit Function
Also, while playing with this stuff, another addition to the FF functions for users and to be used internally by FF would be:
'-- FF_Control_GetClass ---------------------------------------------
'
' Retrieves the Class string of Controls or Forms.
'
' hWndControl: Handle of Control or Form (e.g. HWND_FORM1_COMMAND1)
'
' Returns: The string value set of hWndControl's Class.
'
'------------------------------------------------------------------
Function FF_Control_GetClass(ByVal hWndControl As Dword) As String
Local zString As Asciiz * 255
If IsWindow(hWndControl) Then
GetClassName(hWndControl, zString, SizeOf(zString))
Function= zString
End If
End Function
New Drawing Code:
Case %WM_CTLCOLOREDIT, %WM_CTLCOLORLISTBOX, %WM_CTLCOLORSTATIC, %WM_CTLCOLORBTN
'Message received from child control about to display.
'Set the Color properties here.
'lParam is the handle of the Control. wParam is the hDC.
FF_hDC = wParam
ff_control = GetProp(lParam, "FF_PTR")
If ff_control = 0 Then
If UCase$(FF_Control_GetClass(lParam))= "COMBOLBOX" Then
If UCase$(FF_Control_GetClass(GetParent(lParam)))= "COMBOBOX" Then
ff_control = GetProp(GetParent(lParam), "FF_PTR")
Else
ff_control = GetProp( GetFocus(), "FF_PTR")
End If
If ff_control = 0 Then Exit Select ' Let Def Proc Handle it as it isn't FireFly Created
Else
Exit Select ' Let Def Proc Handle it as it isn't FireFly Created
End If
End If
If @ff_control.ProcessCtlColor Then
SetTextColor FF_hDC, @ff_control.hForeColor
If @ff_control.IsBackSysColor Then
SetBkColor FF_hDC, GetSysColor( @ff_control.BackColorNumber )
Else
SetBkColor FF_hDC, @ff_control.BackColorNumber
End If
'If this is a TextBox then we must use the %OPAQUE STYLE, otherwise
'we will get a lot of screen garbage in the control when scrolling.
If UCase$(FF_Control_GetClass(lParam)) = "EDIT" Then SetBkMode FF_hDC, %OPAQUE Else SetBkMode FF_hDC, %TRANSPARENT
'Return the handle of the brush used to paint the background
Function = @ff_control.hBackBrush
Exit Function
End If
End Select
...
I'm also emailing my project to test if it still fails on Win98, etc so you have the code.
Hi Roger,
I got your email, thanks! I can't deal with your new code until tomorrow because I only have a bit of time tonight to do programming.