QBF object disappearing from forms after building exe in VFP 9
The VFP QBF builder class is used in a maybe six of our projects. Something happened yesterday that is causing the qbf command button to disappear from the forms in all of our projects after building an executable.
If I open VFP and view a form that uses QBF the QBF command button is there. If I then build an executable and reopen the same form, or any others that use QBF, the command button is no longer there. If I close and reopen VFP the QBF command button will be back on all forms again. Or, if I view the base form class where the QBF button is included the button will be there and then it will have reappeared on the forms.
We use VFP 9 SP2 with SourceControl. This system I am seeing the strange behavior is XP SP3.
If I open VFP and view a form that uses QBF the QBF command button is there. If I then build an executable and reopen the same form, or any others that use QBF, the command button is no longer there. If I close and reopen VFP the QBF command button will be back on all forms again. Or, if I view the base form class where the QBF button is included the button will be there and then it will have reappeared on the forms.
We use VFP 9 SP2 with SourceControl. This system I am seeing the strange behavior is XP SP3.
So if you are using source control you should be able to revert into the previous correct version... You should try it at least.
Button can disappear when you set its Visible property to .F. or when you display it outside the visible form area or when you cover it by another control.
Buttons are always visible in design mode independently on their Visible property.
Did you suppress some error messages when building the app?
You should recompile all forms and classes and execute the EXE in VFP IDE Command window by
DO YourApplication.EXE
If you set a breakpoint on a hotkey:
ON KEY LABEL Shift+F11 SET STEP ON
then you should be able to activate the debugger when the form is active and then you may check all form controls.
Button can disappear when you set its Visible property to .F. or when you display it outside the visible form area or when you cover it by another control.
Buttons are always visible in design mode independently on their Visible property.
Did you suppress some error messages when building the app?
You should recompile all forms and classes and execute the EXE in VFP IDE Command window by
DO YourApplication.EXE
If you set a breakpoint on a hotkey:
ON KEY LABEL Shift+F11 SET STEP ON
then you should be able to activate the debugger when the form is active and then you may check all form controls.
ASKER
That is the right QBF.
Unfortunately, I can't roll back soucecontrol because the class hasn't been checked out in years. I have tried to roll back the forms that use the QBF builder and were checked out, but that doesn't seem to have an impact.
It's not the visible property. The object disappears in the development environment as well.
I will try deugging some more and see if I can find the cause. I was messing with error messages around the time of the issue started, so that might be a clue.
Isn't it strange that this effecting all my VFP projects that use the class. Any time I build an executable, recompiling or not, the object is removed from the forms.
Do you think maybe I inadvertantly change a path and VFP can't find QBF after building, but can when it first opens.
Unfortunately, I can't roll back soucecontrol because the class hasn't been checked out in years. I have tried to roll back the forms that use the QBF builder and were checked out, but that doesn't seem to have an impact.
It's not the visible property. The object disappears in the development environment as well.
I will try deugging some more and see if I can find the cause. I was messing with error messages around the time of the issue started, so that might be a clue.
Isn't it strange that this effecting all my VFP projects that use the class. Any time I build an executable, recompiling or not, the object is removed from the forms.
Do you think maybe I inadvertantly change a path and VFP can't find QBF after building, but can when it first opens.
I don't see how a button of a form can disappear through source control. You check in and out a whole form and not the single form elements.
A control can disappear on a form, even in design mode, if it's an ole control and the ole control control isn't registered on the system. But that is accompanied by a message telling so, when you open the form for editing.
Is QBF a collection of ole controls? I don't know it.
Bye, Olaf.
A control can disappear on a form, even in design mode, if it's an ole control and the ole control control isn't registered on the system. But that is accompanied by a message telling so, when you open the form for editing.
Is QBF a collection of ole controls? I don't know it.
Bye, Olaf.
This situation can happen from time to time... The class can be inserted into the form in a wrong way or the form is damaged somehow and the only way how to fix it is to restore the previous correct version.
Strange error messages during the project build must be solved at the first stage. A project can build the EXE even when some components are missing and the EXE behavior is unpredictable then...
And yes, if the path to the class is changed (for whatever reason, e.g. when you move the form into a different folder) then you cannot expect correct project build and some error message appears. If you ignore such message the result can be the class removal from the project...
Even when you did not check out some files for years you should have the last known and bug free VSS version. If you do not store all changes into VSS then you don't need it at all...
You should also make sure the "missing" class is fully accessible by the currently logged-in user.
Strange error messages during the project build must be solved at the first stage. A project can build the EXE even when some components are missing and the EXE behavior is unpredictable then...
And yes, if the path to the class is changed (for whatever reason, e.g. when you move the form into a different folder) then you cannot expect correct project build and some error message appears. If you ignore such message the result can be the class removal from the project...
Even when you did not check out some files for years you should have the last known and bug free VSS version. If you do not store all changes into VSS then you don't need it at all...
You should also make sure the "missing" class is fully accessible by the currently logged-in user.
ASKER
I was finally able to track down some older backups and tried restoring the class, but the issue persists.
The QBF command button class, added to a form class called AppForms, disappears from AppForms if I don't recompile the files while building an executable. If I recompile the files while building the QBF button does not disappear.
New development: If I issue a CLOSE ALL after building without recompiling the QBF button returns to the AppForms class.
The QBF command button class, added to a form class called AppForms, disappears from AppForms if I don't recompile the files while building an executable. If I recompile the files while building the QBF button does not disappear.
New development: If I issue a CLOSE ALL after building without recompiling the QBF button returns to the AppForms class.
Can you please answer the question, if QBF is an ole control? I can't help, if I only know half the facts.
And what does this mean? Is that (returning to the AppForms) what the QBF button should do?
Before I compile/build an EXE I restart VFP, because you can have any kind of flaws, if classes are still loaded into memory, while you compile. It just takes about 5 seconds to start VFP.
Do that and see, if it helps. anyway, it's not sufficient to restore a class and put it anywhere. As Pavel said, if path/location of class isn't as it should be, if the class or the form using the class has changed location, then the build cannot be correct.
Bye, Olaf.
New development: If I issue a CLOSE ALL after building without recompiling the QBF button returns to the AppForms class.
And what does this mean? Is that (returning to the AppForms) what the QBF button should do?
Before I compile/build an EXE I restart VFP, because you can have any kind of flaws, if classes are still loaded into memory, while you compile. It just takes about 5 seconds to start VFP.
Do that and see, if it helps. anyway, it's not sufficient to restore a class and put it anywhere. As Pavel said, if path/location of class isn't as it should be, if the class or the form using the class has changed location, then the build cannot be correct.
Bye, Olaf.
This behavior just means "Some file remains open which prevents the QBF to initialise"...
VFP isn't perfect and it still has some bugs not fixed. In addition to this developers can do unpredictable actions... Some objects can remain open because a reference to them or one of their components still exists. This can result in unfinished cleanup and impossibility to use the class in further app run.
Tracing the QBF initialisation code should show what file/command causes this problem but the fastest solution really is to issue CLOSE ALL...
BTW, is Classy Components alive? Their web is dead but I did not test email published on VFP wiki: http://fox.wikis.com/wc.dll?Wiki~JacobBruner
VFP isn't perfect and it still has some bugs not fixed. In addition to this developers can do unpredictable actions... Some objects can remain open because a reference to them or one of their components still exists. This can result in unfinished cleanup and impossibility to use the class in further app run.
Tracing the QBF initialisation code should show what file/command causes this problem but the fastest solution really is to issue CLOSE ALL...
BTW, is Classy Components alive? Their web is dead but I did not test email published on VFP wiki: http://fox.wikis.com/wc.dll?Wiki~JacobBruner
ASKER
QBF is not an OLE object. I believe Classy Components is no more.
See the attached screenshot. Note QBF is a class included in the project. You can see cmdQBF from that class located lower center of the opened appForms class, form_CriteriaCS. If I build an executable without recompiling and then modify form_CriteriaCS again, cmdQBF would not be there and thereafter while running the program the forms based on form_CriteriaCS fail because cmdQBF cannot be found.
My apologies, CLOSE ALL does not release the cmdQBF class. It is CLEAR ALL that does.
The issue persists for all projects containing the QBF class. These projects all use SourceSafe. They all exists in their own directory, but they are all copies of an original project. Something in the copied projects must be pointing back to the original project, causing them all to have this issue.
ScreenShotWithQBFcmdButtonOnForm.bmp
See the attached screenshot. Note QBF is a class included in the project. You can see cmdQBF from that class located lower center of the opened appForms class, form_CriteriaCS. If I build an executable without recompiling and then modify form_CriteriaCS again, cmdQBF would not be there and thereafter while running the program the forms based on form_CriteriaCS fail because cmdQBF cannot be found.
My apologies, CLOSE ALL does not release the cmdQBF class. It is CLEAR ALL that does.
The issue persists for all projects containing the QBF class. These projects all use SourceSafe. They all exists in their own directory, but they are all copies of an original project. Something in the copied projects must be pointing back to the original project, causing them all to have this issue.
ScreenShotWithQBFcmdButtonOnForm.bmp
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
DISPLAY OBJECTS AND DISPLAY MEMORY yielded nothing obvious, like you figured.
Olaf's prg created a table called rFolderLabels. rFolderLabels is a form I created and added to the project about the time the issue started. Each record in the table was for objects on rFolderLabels.
I removed rFolderLabels from the project and still the QBF issue persists. rFolderLabels is a simple form that does not include the QBF class.
I too have run into issues with SourceSafe and ReadOnly settings. Not finding that this time.
Olaf's prg created a table called rFolderLabels. rFolderLabels is a form I created and added to the project about the time the issue started. Each record in the table was for objects on rFolderLabels.
I removed rFolderLabels from the project and still the QBF issue persists. rFolderLabels is a simple form that does not include the QBF class.
I too have run into issues with SourceSafe and ReadOnly settings. Not finding that this time.
What are you talking about creating a table? I open SCX and VCX as a tables, because they are tables, I don't create tables. If a file was missing, the line [? "Missing file...] would print the missing file to the screen. If nothing is output by the program, it just leaves the last project component it found open as a table. That's merely not tidying up, sorry, put a USE at the end.
That was not at all a hint on removing that part off your project, you misunderstand that.
Bye, Olaf.
That was not at all a hint on removing that part off your project, you misunderstand that.
Bye, Olaf.
ASKER
Ha. Got it. It was easy enough remove and re-add the form to the project in case there was something inadvertently was accessing the QBF class, so I just gave it a try.
I modified your prg a bit and dumped the results into a text file. There are 4073 records.
I 'm sure I created this issue. I changed something while working on the project one day last month and I have yet to figure out what that was yet.
I may come back to this again later, but have to let it go for now and settle with closing VFP or issuing a CLEAR ALL after building exe. Or recompiling.
As always, thanks to both of you! Any final thoughts?
I modified your prg a bit and dumped the results into a text file. There are 4073 records.
I 'm sure I created this issue. I changed something while working on the project one day last month and I have yet to figure out what that was yet.
I may come back to this again later, but have to let it go for now and settle with closing VFP or issuing a CLEAR ALL after building exe. Or recompiling.
As always, thanks to both of you! Any final thoughts?
I am still voting for CLEAR ALL. But if you find another solution let us know please.
Well, I would exit and restart VFP before building an exe, but not afterwards.
If you're only having a problem after a build, then look out, if the project has a project hook doing something stupid in beforebuild or afterbuild events.
Bye, Olaf.
If you're only having a problem after a build, then look out, if the project has a project hook doing something stupid in beforebuild or afterbuild events.
Bye, Olaf.
ASKER
I have tried a few other things to resolve this issue, but it still persists. I have to close this ticket. I will follow up with notes if we do find a solution. For now, CLEAR ALL does the trick.
It's not a part of VFP, it's a third party component. I don't know about it, but code can stop working. Debug is the best advice I can give. Reinstall another one.
Bye, Olaf.