VFP 9 SP2.
I have an application that when run in developer mode runs correctly.
The application has a form with a lstbox. On the dblclick() of the list box a child form opens.
The parent screen behind it redraws the controls on the form, just slightly below the original positions of the original controls. It only occurs when running the exe standalone. The forms are based off a class in a class library. Not sure why this started.
FoxPro
Last Comment
kpi_it
8/22/2022 - Mon
Pavel Celba
This sounds like an issue with display adapter. Does it occur on all available PCs?
Another possibility is a Private data session and TALK not switched to the OFF state.
What happens after parent form Refresh method call?
kpi_it
ASKER
Not a display adapter as this just started.
And only occurs when running the exe standalone.
Set talk is off.
It occurs on the splashscreen, and a couple of other screens but not all of them.
Hard to test as everything runs correctly in dev mode.
Does your splash screen contain a list box as you describe in the question?
kpi_it
ASKER
Yes and no on the private datasessions.
It is parent / child form dependant.
Some share the same data while other have private sessions.
Splash screen is just a form based on the form class.
It just has text boxes to display the info and a company logo on it.
The issues seems to be that during a refresh of the form it positions everything down a little and to the right. And redraws the controls. It is odd. There is no resizing class on these forms.
dfolger
I experienced a similar problem in an app a few years ago.
It was caused by CONSOLE being set ON and using the "BELL" CHR() funtion to make a sound:
?? CHR(7)
If CONSOLE is set ON and you issue this ?? CHR(7) statement, all controls on the form will "jump" and double up as you described.
Are you using a chr(7) anywhere in your app?
When any error occurs in VFP "SET CONSOLE" gets set to "ON".
Make sure if you are trapping errors, that you immediately SET CONSOLE OFF.
Also make sure your form's base class has "SET CONSOLE OFF" statement in its "LOAD" method.
Also make sure you SET CONSOLE OFF before issuing a ??chr(7).
Found that the issue with doubling up is during the load of the form.
Just before the call to the child form set('talk') is off.
But when you stop in the middle of the load of the child form set('talk') is on.
If I place a wait '' nowait just before the call to the child form the issue goes away.
I am thinking corrupted data of some sort in the form tables but not sure.
SET TALK ON is a default setting for each Private Data Session. You have to set it OFF as soon as possible on each form.
SET TALK ON causes control shifting on a form because many commands are "echoed" to the output.
Data are not corrupted most probably.
Pavel Celba
I am just curious how the accepted solution could help in your case... Isn't it better to delete the question if we are not able to help or if you resign to communicate with us?
Well actually you are probably correct. As I don't use this site often enough to know it's ins and outs. I didn't realize it was possible to close it from my end. I should read up more on this. Also I had some research to do and this question being abandoned was keeping me from it. Thanks for the input.
Another possibility is a Private data session and TALK not switched to the OFF state.
What happens after parent form Refresh method call?