none
FPW 2.6 to VFP 9.0 Compatibility

    Question

  • Hi.  Been working on bringing over code to VFP 9.0.  Added _screen.Themes = .F. to my old code to fix color set problems (I thank the people in this forum for the help).  Now try this:

    && _screen.Themes = .F.

    DEFINE WINDOW TEMP FROM 0,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM
    DEFINE WINDOW TEMP2 FROM 4,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM

    ACTIVATE WINDOW temp
    @ 0,0 SAY 'Hi'

    USE mail
    BROWSE WINDOW temp2 IN WINDOW temp

    RELEASE WINDOW temp
    RELEASE WINDOW temp2

    If you add _screen.Themes = .F., the color in window temp becomes affected but only the first time you run the code.  Run it again, it's fine.  Is there anything I can do?

    Tuesday, February 19, 2013 8:22 PM

Answers

  • I see what you mean.

    Okay, I found a workaround. Add the Name clause to the first DEFINE WINDOW command and then right before the Browse, set the window's backcolor as you want it:

    DEFINE WINDOW TEMP FROM 0,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM NAME oTemp
    
    * other code
    
    oTemp.BackColor = RGB(0,0,255) && that's not the right color
    
    BROWSE ...
    * rest of code
    Tamar

    Thursday, February 21, 2013 9:13 PM
    Moderator
  • I would say the only workaround is "Don't change _screen.Themes during the program run"...

    Following code works without problems when you execute it repeatedly as fast as possible (e.g. by pressing CTRL+E in PRG edit window):

    _screen.Themes = !_screen.Themes
     
    DEFINE WINDOW TEMP FROM 0,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM NAME oTemp
    ACTIVATE WINDOW temp
    oTemp.BackColor = RGB(0,0,255) 
    oTemp.ForeColor = RGB(255,0,255)
    
    DEFINE WINDOW TEMP2 FROM 4,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM
    
    @ 0,0 SAY 'Hi'
    ? _screen.Themes
     
    USE SomeTable ...
    
    BROWSE WINDOW temp2 IN WINDOW temp
      
    RELEASE WINDOW temp
    RELEASE WINDOW temp2
    

    Once you allow a delay (2 seconds is enough) between two program runs so that VFP will execute some cleanup (garbage collection etc.) the text is not visible in the next run...

    And now the question is: Whom to ask for the fix?

    Thursday, February 21, 2013 10:41 PM
    Moderator

All replies

  • That is really strange. I can replicate it. I thought perhaps I could fake it out by defining, activating and releasing Temp once before the real code, but that doesn't help.

    Okay, even weirder. When I step through the code in the Debugger, it doesn't happen. I also tried putting a breakpoint at a couple of different places to see where this happens. Doing that let me see that the window starts out blue, but turns white.

    Don't know whether any of this will help.

    Tamar

    Tuesday, February 19, 2013 9:47 PM
    Moderator
  • I see this happening with the browse command and the suspend command.  Perhaps someone can find a command we could use after _screen.Themes = .F.  that wouldn't effect the application, yet shake loose this behavior...Dennis
    Wednesday, February 20, 2013 1:15 AM
  • Yes, it's strange. It continues to get stranger. After you uncommented _screen.themes = .F. and ran the code twice, it seems stable. But if you then turn _screen.themes = .t. the same thing happens: In the first start the form background will not be dark blue but light beige/sand. And if you stay with themes the second run also looks okay again.

    So it seems changing themes does cause this, no matter how you change it.

    Overall themes=.f. of course is helping legacy code to have control about the looks, so that's not the point.

    The point is, there seems to be something not reset correctly, whenever you change themes. I have tried using SYS(2700) instead or additional to _screen.themes, hoping it does a bit different, additonal or less, but it doesn't work.

    It obviously has to do with the browse. Help on the browse IN WINDOW clause says: "The Browse window doesn't assume the characteristics of the parent window."

    That doesn't explain why the browse would effect the background of temp, but it does.

    And what really works is setting the browse window themes:

    ...

    BROWSE WINDOW temp2 NAME oBrowse NOWAIT IN WINDOW temp 
    oBrowse.Themes = .F.
    Wait window ''

    ...

    But that of course needs a new wait state, because you can only set oBrowse.Themes=.f. when you add the NOWAIT clause to the browse, and then execution doesn't stop until the browse window is closed, so you need a WAIT WINDOW '' or anything like that.

    Not really helpful, but the reason seems to be the browse.themes setting affecting the parent window.

    Bye, Olaf.


    • Edited by Olaf Doschke Wednesday, February 20, 2013 8:07 AM
    Wednesday, February 20, 2013 8:06 AM
  • Interesting!

    If you place  _screen.Themes = !_screen.Themes   at the beginning the bug is still there...

    Unfortunately, I don't have a solution for the bug removal...

    So the only solution is to set _screen.Themes just once at the program beginning and keep it unchanged during the program run. It is the way how it was tested probably...

    Another way is to switch to VFP forms completely.

    Wednesday, February 20, 2013 11:09 AM
    Moderator
  • It still happens if you perform just the browse.  Why would the browse affect windows not even associated?

    BROWSE   && WINDOW temp2 IN WINDOW temp

    Wednesday, February 20, 2013 8:47 PM
  • The BROWSE isn't the issue. If I set a breakpoint on the USE line, when the break occurs, the window has already turned white. In fact, a breakpoint on the @0,0 line shows the same thing. Even a breakpoint on the Activate line, followed by stepping through that line shows it, too.

    What I don't understand is why creating, activating and deactivating the window doesn't count as the first time, so that then it will work.

    Tamar

    Wednesday, February 20, 2013 9:29 PM
    Moderator
  • I think you're seeing an interaction with the debugger.  Run it straight, replace BROWSE with WAIT WINDOW and it's fine.  Replace BROWSE with SUSPEND to the command window will also make it happen.
    • Edited by dallen24 Wednesday, February 20, 2013 10:50 PM
    Wednesday, February 20, 2013 10:49 PM
  • I see what you mean.

    Okay, I found a workaround. Add the Name clause to the first DEFINE WINDOW command and then right before the Browse, set the window's backcolor as you want it:

    DEFINE WINDOW TEMP FROM 0,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM NAME oTemp
    
    * other code
    
    oTemp.BackColor = RGB(0,0,255) && that's not the right color
    
    BROWSE ...
    * rest of code
    Tamar

    Thursday, February 21, 2013 9:13 PM
    Moderator
  • I would say the only workaround is "Don't change _screen.Themes during the program run"...

    Following code works without problems when you execute it repeatedly as fast as possible (e.g. by pressing CTRL+E in PRG edit window):

    _screen.Themes = !_screen.Themes
     
    DEFINE WINDOW TEMP FROM 0,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM NAME oTemp
    ACTIVATE WINDOW temp
    oTemp.BackColor = RGB(0,0,255) 
    oTemp.ForeColor = RGB(255,0,255)
    
    DEFINE WINDOW TEMP2 FROM 4,0 TO 24, 78 COLOR W/B FLOAT CLOSE GROW ZOOM SYSTEM
    
    @ 0,0 SAY 'Hi'
    ? _screen.Themes
     
    USE SomeTable ...
    
    BROWSE WINDOW temp2 IN WINDOW temp
      
    RELEASE WINDOW temp
    RELEASE WINDOW temp2
    

    Once you allow a delay (2 seconds is enough) between two program runs so that VFP will execute some cleanup (garbage collection etc.) the text is not visible in the next run...

    And now the question is: Whom to ask for the fix?

    Thursday, February 21, 2013 10:41 PM
    Moderator