text written to screen gets erased when browse screen is opened

[idleweiss]

Weird behavior in VFP9 (works fine in 7).
Text written (@say) to screen gets cleared when
browse screen is displayed in a new window.

Only happens when VFP9 is first started and
routine is run the first time. Subsequent
execution of the same routine the text display
does not get cleared.

 

[Mike Lewis]

I'm not seeing this behaviour. There must be some other factors at work here.

You talk about a "routine" being run. That suggests you are running some code to open the Browse window. If that's so, it could be something in the code that's causing the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

@say

You aren't still using the OLD, OLD Foxpro-DOS method of displaying information are you?
Most especially not in a Visual Foxpro application?

While it may not have anything to do with the problem you are encountering, you should move up to at least the 20th century (if not the 21st) and change that method of coding.

Good Luck,
JRB-Bldr

 

[idleweiss]

The following code snippet runs fine in both VFP7 and 9 on initial load of VFP. With a more complex set of @ says (my real app) and other upfront code, the @say strings (e.g., "sdlkjlsdkflsdjflsdj") get cleared as soon as the brow screen is activated -- but only on the first load of VFP9 -- works fine in VFP7.

Just trying to see if anybody else has run into this issue.

There also are other backward compatibility issues (like enginebehavior on group by statements) that may keep me with VFP7 -- at least I know that version is rock hard stable and meets my needs. Dang MS>>>

********************************
clear

@ 5,20 say "sdlkjlsdkflsdjflsdj"

CLOSE DATABASES
use c:\bni\dbfs\po_detl

DEFINE WIND PO_ADD2 ;
FROM 11,0.5 TO 35.2,76.0

ACTIVATE WIND PO_ADD2
SHOW WIND PO_ADD2

BROW FIELDS ;
ITEMNO :08 :H="Item#" ;
NODELETE NOAPPEND NOMENU ;
FREEZE ITEMNO NOEDIT
release WIND PO_ADD2
close data
cancel
********************************

 

[Mike Lewis]

No, still not seeing the problem you describe. I ran your code in VFP 9, and the text stayed on the screen, as expected.

If the purpose of your question is to decide whether or not to upgrade from VFP 7 to 9, my advice would be not to bother. At risk of sounding facetious (I don't mean to be), I would echo JRB-Bldr's sentiments - you might as well be using FoxPro for DOS.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[idleweiss]

Thanks for the thoughtful feedback folks -- I hear what you say about getting into the 21st century -- given that, it will not be with VFP since MS has decided to make it "History"

 

[Dan Freeman]

I'm wondering why you're bothering with the window definition at all. You're not using the window in your browse command. What are you using it for?

What have you left out of this code? Whatever that is, it's likely to be hiding your culprit, and we can't see it since you're not showing it to us.

(If you're doing away with @ SAY, you should also do away with DEFINE WINDOW and BROWSE, by the way.)

 

[TamarGranor]

Make sure to turn themes off. _SCREEN.Themes = .F.

Tamar

 

[idleweiss]

Tamar: From a post you made elsewhere (thanks a bunch) I already did the _screen.Themes=.F. and enginebehavior70 trick to eliminate other bad behaviors in VFP9 that made my nerves tingle (not to mention losing 20 or so hours of time dealing with "M$'s enhancements".

Bottom line is that I plan to stick with version 7.0 since it has all the features I need and isn't flacky processing code from the previous century.

Had to look deep in the pile to find my original version 7 CD -- with Win7 I had to formally install it instead of just copying the VFP7 folder to hard drive and run it from there as was possible with XP.

Also, buying version 7 from M$, Amazon, eBay and other places I looked is impossible.

Incidently, the business reason for converting the classic FoxPro for DOS 2.6 app to Windows is the fact that 64 Win7 no longer runs 16 bit apps and 32 bit machines probably may no longer be available in several years. The existing app has now been running for 15 years without issue, so there is no real urgency in getting the conversion online. The existing DOS app runs fine on 32bit Win7.

Off soapbox...

 

[Mike Lewis]

I already did the _screen.Themes=.F. and enginebehavior70 trick to eliminate other bad behaviors in VFP9

Just to be clear ..... SET ENGINEBEHAVIOR 70 is not a trick to emiminate "bad behaviors". On the contrary, it switches off the good "behaviors" in VFP 9.0. It maintains backward compatibility with VFP 7.0, at the expense of allowing you to execute potentially harmful SQL.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike,

while that's true, someone having an application working and time-tested will not understand it that way, even if it's right.

In fact just taking the group by behavior: It's of course less ambigous now, but if you consider the behavior of vfp7 for non aggregated and non grouped fields, to put in the value of the first group record, the grouping does work reproducable and reliable and it's easier to just set enginebehavior to 70 to keep it working.

You can do the same in 90, but it needs more accuracy.

I agree vfp9 is not at all bad, it's stricter and therefore helping better to make better quality queries. And besides behavior changes it offers a lot of more options and features that makes it the better vfp.

If you're confronted with errors in a working app, that of course is a bummer. But, idleweiss you would have much less of these "annoying" errors, if you would have migrated in time, version by version.

Besides all that I heard from many vfp developers going through all the versions, that vfp6 and 7 where some of the most buggiest versions of vfp, vfp6 had 5 service packs, vfp7 only 1, but some of the errors where then only fixed in vfp8. Bloating index files and more likely table corruptions are two "features" of vfp7 I can do without for sure.

Bye, Olaf.

 

[idleweiss]

Thanks for all the feedback -- I am getting more frustrated with this VFP thing as time goes on -- now I find that VFP7 is really not compatible with Win7 -- while it loaded and ran fine on the app after I initially installed VFP7, it failed to load after a Win7 reboot.

Right clicking on the VFP7 Icon, selecting "troubleshoot compatibility", accepting the recommended changes to XP compatibility mode, and then choosing "Start the Program", it started and I was able to run the app correctly without issue and with desired behavior.

Saving the compatibility changes, and pressing <Next> resulted in a "incompatible application" message and basically put me back at square one.

So, it's either deal with the VFP9 issues I encountered and implement a workaround/fix or abandon the VFP stagecoach entirely -- dang and double dang.

Since I am 75, maybe it is just time to go sailing instead

Thanks again for your feedback...

 

[idleweiss]

WhooHooo -- Problem solved by workaround as follows:

Instead of writing the @SAYs within an activated window,
I wrote the @SAYs directly to the screen via a WHEN()
clause from a browse statement within a defined window.

Cause of the initial buggy behavior was the
"_SCREEN.THEMES" command.

-- For the buttons and fields to not disappear when the
window was in focus, _SCREEN.THEMES had to be set
to .F. per Tamar's post.

-- For the @SAYs to be properly displayed, and not be cleared
_SCREEN.THEMES had to be set to .T.

-- Attempting to toggle the setting back and forth did not
work, so I was caught with a choice, make the browse option
work with it set to .T. or make the within window buttons
and fields work with it set to .F.

-- Using the WHEN() command within the browse permitted the
proper behavious of both with SCREEN.THEMES set to .F. albeit
not as efficient as I would like, but at least it works
reliably as desired.


Further to the point, I am looking into switching from VFP back to dBASE PLUS -- see

http://www.dBASE.com

 

[Olaf Doschke]

FYI, the global _screen.themes setting can be ovverriden with each controls themes property. That may also help.

Your observation "For the @SAYs to be properly displayed, and not be cleared _SCREEN.THEMES had to be set to .T." makes me wonder, though, as users having problems with legacy foxpro screens always reported only themes = .t. is problematic and leads to controls being cleared when you mousover. So that's news. Did you install sp2? It surley does not make themes work, but it might make it at least consequently only working in themes=.f. mode.

You may also try SYS(2700), it's about the same as _screen.themes, but the help notes some differences especially when reading the current setting.

The best bet by my state of knowledge still is to put _screen.themes = .f. or sys(2700,0) at the very first thing an app does before rendering any @say.

Bye, Olaf.

 

[idleweiss]

Olaf:

-- that is exactly what I did -- put _screen.themes = .f.
at the very first thing in app. Did not know about 2700.

-- am running SP2.

-- running into the (I'll call it a bug) with the @SAY
clear problem was a real show stopper for this
particular app since it is the browse screen with
ON KEY LABEL commands that is used to do all
add/edit/delete/print/lookup operations while also
displaying reference information surrounding the browse
screen that runs in a fixed window -- all hotkey driven.
No mouse to slow down operation of this point-of-sale app.

I am now a kinda/sorta VFP9 happy camper with the very
workable WHEN() command solution -- but still am looking
into the "back-to-dBASE" alternative for the long haul.

 

[Olaf Doschke]

The help says something special about the case you use hottracking as specialeffect, but that's probably also not the cause, as you optimised your screens for keyboard usage.

Well, then, problem solved, case closed.

Bye, Olaf.