Paul
I did a quick check of a code sent me by a FF user, it seems that since you have moved to Jose's CWindow class, there is a conflict between WinLIFT and the encapsulation of the Jose's class.
Looks like a lot of extra processing is done after the call to the code of the FORM_WM_CREATE, that defeats the use of the WinLIFT subclassing engine. No more changes must be done to the window (class and size) at the time the skSkinWindow is being used.
Is it possible to turn off the use of the CWindow class within FireFly?
Hi Patrice, is it this type of code that is causing trouble?
pWindow.ClassStyle = %CS_VREDRAW Or %CS_HREDRAW Or %CS_DBLCLKS
pWindow.Brush = %COLOR_BTNFACE + 1
pWindow.SmallIcon = LoadIcon( App.hInstance, ByVal %IDI_APPLICATION )
pwindow.BigIcon = LoadIcon( App.hInstance, ByVal %IDI_APPLICATION )
pWindow.CenterWindow
Function = FLY_DoMessagePump( ShowModalFlag, pWindow.hWnd, hWndParent, %SW_SHOWNORMAL, IsMDIForm )
Turning off cWindow is not possible but hopefully I can create a solution for you.
Paul
User's project has been sent to you.
Thanks.
Hey,
Wondered if there was any advancement of info in relation to this thread ? I have a vested interest in using FF and WinLIFT: http://www.planetsquires.com/protect/forum/index.php?topic=3319.0 (http://www.planetsquires.com/protect/forum/index.php?topic=3319.0)
Thanks in advance,
Steve
Yes, there appears to be issues with the versions of FireFly that use cWindow class and the WinLift package. One is a flickering issue that I can fix but the second is a problem that I can not understand why it occurs. Basically popup windows do not size correctly.
cWindow is probably doing things occuring after WinLIFT has done its own job.
The solution would be to edit manually the source code generated by Fly, but that of course would defeat the purpose of Fly.
WinLIFT works well with plain SDK and DDT code, as long as they are not using subclassing to post process some native Windows messages, especially those NC_messages related to the non-client area.
All the tests i did were done a few years ago with Fly version 3.00, that worked well with WinLIFT.
Currently all my time (and more) is eaten by the translation of my code to 64-bit, and my strategic decision to move away from PB.
The only thing that it does is to save a pointer to the class in the 4 extra bytes reserved in cbWndExtra.
WinLIFT is also using it in its skBorder API, i don't know if that would cause the problem or not.
FUNCTION skBorder ALIAS "skBorder" (BYVAL hWnd AS LONG, BYVAL x AS LONG, BYVAL y AS LONG, BYVAL xW AS LONG, BYVAL yH AS LONG, BYVAL nID AS LONG, BYVAL nBorder AS LONG) EXPORT AS LONG
LOCAL wc AS WNDCLASSEX
LOCAL zClass AS ASCIIZ * 10
LOCAL hCtrl, IsInitialized AS LONG
LOCAL hParent, hInst, nItem AS LONG
LOCAL rw AS RECT, pt AS POINTAPI
hInst = skInstance()
zClass = "SKBORDER"
wc.cbSize = SIZEOF(wc)
IsInitialized = GetClassInfoEx(hInst, zClass, wc)
IF IsInitialized = 0 THEN
wc.cbSize = SIZEOF(wc)
wc.style = 0 '!!// %CS_HREDRAW OR %CS_VREDRAW
wc.lpfnWndProc = CODEPTR(BorderProc)
wc.cbClsExtra = 0
wc.cbWndExtra = %EXTEND_PROPERTY * 4
wc.hInstance = hInst
wc.hIcon = %NULL ' LoadIcon(wc.hInstance, "PROGRAM")
wc.hCursor = %NULL
wc.hbrBackground = %NULL ' Don't paint the class window background
wc.lpszMenuName = %NULL
wc.lpszClassName = VARPTR(zClass)
wc.hIconSm = wc.hIcon
IF RegisterClassEx(wc) THEN IsInitialized = %TRUE
END IF
'
IF IsInitialized THEN
hCtrl = CreateWindowEx(0, zClass, "", %WS_CHILD OR %WS_VISIBLE, _
x, y, xW, yH, GetParent(hWnd), nID, hInst, BYVAL %NULL)
IF hCtrl THEN
CALL GetWindowRect(hWnd, rw)
hParent = GetParent(hWnd): pt.X = 0: pt.Y = 0: CALL ClientToScreen(hParent, pt)
CALL skSetProperty(hCtrl, %BORDER_BRUSH, skGetSysColor(%SKCOLOR_EDITCOLORBACK))
CALL skSetProperty(hCtrl, %BORDER_UP, skGetSysColor(%SKCOLOR_EDITCOLORRECTUP))
CALL skSetProperty(hCtrl, %BORDER_DOWN, skGetSysColor(%SKCOLOR_EDITCOLORRECTDOWN))
CALL skSetProperty(hCtrl, %BORDER_SIZE, nBorder)
CALL skSetProperty(hCtrl, %BORDER_DELTAX, rw.nLeft - pt.X - x)
CALL skSetProperty(hCtrl, %BORDER_DELTAY, rw.nTop - pt.Y - y)
CALL skSetProperty(hCtrl, %BORDER_DELTAW, xW - (rw.nRight - rw.nLeft))
CALL skSetProperty(hCtrl, %BORDER_DELTAH, yH - (rw.nBottom - rw.nTop))
CALL skSetProperty(hCtrl, %BORDER_WINDOW, hWnd)
nItem = skChild(hWnd): IF nItem THEN Child(nItem).hBorder = hCtrl
' hRgnClip = CreateRectRgn(0, 0, xW, yH)
' hRgn = CreateRectRgn(0, 0, xW - (nBorder * 2), yH - (nBorder * 2))
' CALL OffsetRgn(hRgn, nBorder, nBorder)
' CALL CombineRgn(hRgnClip, hRgnClip, hRgn, %RGN_XOR)
' CALL skDeleteObject(hRgn)
' CALL SetWindowRgn(hCtrl, hRgnClip, %FALSE)
CALL BorderProc(hCtrl, %WM_SIZE, 0, 0)
CALL skSkinDisable(hCtrl)
END IF
FUNCTION = hCtrl
END IF
END FUNCTION
You must check the value of cbWndExtra and add your extra bytes after the returned value. Same with cbClsExtra.
If you overwrite the pointer stored, then the application can't work.
I don't know if this is the problem or not, because skBorder is a window created on the fly by WinLIFT, so i feel free to use the cbWndExtra as i want.
Until i have time to spend on this, please consider that WinLIFT doesn't work anymore with Fly 3.50+
Then it must not be the problem. I thought that you were changing the information of the main window.
The skBorder API is responsible for the skinning of the scrollbars, daunting task for sure, because the scrollbars are drawn directly by the OS (tooks me 10 years before i could find a solution to do it on the fly).
Forcing me to hook the messages to bypass the OS.
Hello and Happy New Year,
Anyone know if this issue has been resolved?. I would like to try to use Winlift with FF3 again.
Thank you in advance,
Ron
Ron--
I don't think it would work with the new predefined class container used in Fly since version 3.50, but i haven't done any test myself.
I shall post soon a new project using only VISUAL GRAPHIC COMPONENTS rather than {classic} custom controls.
I mean all the interface would be embedded inside of one single GDImage control, using sprites that behave like {standard} Windows controls.
Most programmers have mental barriers that limit their understanding of how Windows really work:
The whole Windows interface is indeed a graphic container, where the desktop is at the bottom of the z-order and all the popup {child} windows are widget layers, floating above the desktop in opaque or transparent mode (AERO or WS_EX_LAYERED).
The project i am speaking about is working exactly the same, based on mousing interaction with the GDImage sprites. The main advantage of this approach is that you are not limited by what are doing specific classes like: button, static, listbox, etc. And the resulting interface will always have the same look whatever the version of the OS.
With the extra benefit to work in full composited mode, and being able to use variable opacity with ALL sprites/child controls
It would also ease the porting between 32 or 64-bit, because the syntax is exactly the same what ever the language used.
Getting rid of predefined child control classes open a level of freedom, you would never think possible with mental barriers. :)
...
Patrice - I sent you email the other day - wanting to order an update!
When you get the chance - I'm in no rush!
Thanks
Michael
QuoteThis is the mail system at host mwinf5d20.orange.fr.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.
The mail system
<mmeeks@cityofseward.net>: host cityofseward.net[209.124.136.55] said: 554
5.7.1 Message rejected because of unacceptable content. For help, please quote incident ID 01OhjSleQ.
and here is what was my answer to you:
QuoteMichael
Please accept my apologies for the delay.
First, you must check that the current version is working for you, downloading the trial version from here:
http://www.zapsolution.com/DW/US/winlift.html
Second, if you are using the latest FireFly using the Jose Roca’s cwindow class it will probably not work with WinLIFT, because the “dpi aware†concept being used defeats the whole purpose of the SkinEngine.
Third, there is no upgrade policy to the current version because it is a totaly new skin engine, reworked from ground zero, to be compatible with the 64-bit version written in C++.
Fourth, the current skin themes provided with the package are those shown with a red dot there:
http://www.zapsolution.com/DW/US/skinroom.html
the others must be ordered from a distinct skin pack.
Fifth, since PowerBASIC is frozen in time, i have no plan to provide further development on that platform.
You can find many examples here:
http://www.jose.it-berater.org/smfforum/index.php?board=379.0
Best regards
patrice
www.zapsolution.com