WinLIFT and CWindow class

[Patrice Terrier]

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?

[Paul Squires]

Hi Patrice, is it this type of code that is causing trouble?

Code Select Expand


    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.

[Patrice Terrier]

Paul

User's project has been sent to you.

Thanks.

[Stephen Pardoe]

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

Thanks in advance,

Steve

[Paul Squires]

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.

[Patrice Terrier]

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.

[José Roca]

The only thing that it does is to save a pointer to the class in the 4 extra bytes reserved in cbWndExtra.

[Patrice Terrier]

WinLIFT is also using it in its skBorder API, i don't know if that would cause the problem or not.

Code Select Expand

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

[José Roca]

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.

[Patrice Terrier]

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+

[José Roca]

Then it must not be the problem. I thought that you were changing the information of the main window.

[Patrice Terrier]

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.

[Dennis Allen]

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

[Patrice Terrier]

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.

...

[Michael Meeks]

Patrice - I sent you email the other day - wanting to order an update!
When you get the chance - I'm in no rush!

Thanks