Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.
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.
Who is Participating?
What is QBF? Well, I see it mentioned here: http://fox.wikis.com/wc.dll?Wiki~QBF
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.
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.
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.
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.
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
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
If you checkout from Source Safe take a look at readonly flags of files. Someone at a customer reported to have problems with this "feature" of SourceSafe.
Also you can easily check out, if any project component points to some file missing.
You can have the effect of seeing a button, once it's class is loaded into memory, because VFP then doesn't try to read a file, classlib and class are already loaded into memory. Then after CLEAR ALL they are not anymore, because CLEAR ALL also CLEARs CLASSLIBS and CLASSES.
Indeed that would only explain the inverse problem, if you cannot see the QBF button anymore, after you CLEAR ALL, and only see it, after Classy Components have initialized and perhaps loaded classes into memory by SET CLASSLIB.
Give it a try to search for "broken links". Put the following code into a prg, then open your project, and start the prg. It will point out missing files in regard to Classloc info in each SCX or VCX record.
Also you can easily check out, if any project component points to some file missing.
You can have the effect of seeing a button, once it's class is loaded into memory, because VFP then doesn't try to read a file, classlib and class are already loaded into memory. Then after CLEAR ALL they are not anymore, because CLEAR ALL also CLEARs CLASSLIBS and CLASSES.
Indeed that would only explain the inverse problem, if you cannot see the QBF button anymore, after you CLEAR ALL, and only see it, after Classy Components have initialized and perhaps loaded classes into memory by SET CLASSLIB.
Give it a try to search for "broken links". Put the following code into a prg, then open your project, and start the prg. It will point out missing files in regard to Classloc info in each SCX or VCX record.
FOR EACH loFile in _vfp.ActiveProject.Files
If loFile.Type $ "VK" && VCX or SCX
Use (loFile.name)
Scan For Not Empty(Classloc) and ADir(laDummy,FullPath(Classloc,JustPath(loFile.name)))=0
? "Missing file "+FullPath(Classloc,JustPath(loFile.name))
EndScan
EndIf
ENDFOR
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.
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?
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.
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.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
If some pending object reference avoids the class including into the final project then the CLEAR ALL + CLOSE ALL + RELEASE ALL is the last command combination which helps obviously. VFP restart is even better.
Pending references can be caused either by your programming techniques or by VFP itself. This one I am counting to VFP because it raised as unexplained and it is still here... You could issue DISPLAY MEMORY and DISPLAY OBJECTS before and after the CLEAR ALL and compare results. Of course, above commands do not show everything.
I am issuing CLEAR ALL automatically in error handler when error 1948 (Cannot modify a class that is in use) occurs. CLEAR CLASS could be sufficient but I also don't know why the class remains in memory and the reset ensures no further problems. Omitting CLEAR ALL resulted in C000005 exception sooner or later in my case.
Neither me nor Olaf has QBF available and we cannot reproduce the behavior described.
Your project build does not report any error which (again) points to a VFP bug and everything you can do is to use some work around now. So the CLEAR ALL is a good (or even the best) solution at the moment.
If you are happy to spend hours looking where the error is or what causes it then create a new empty project and add your classes one by one into this new project. You'll see when the build fails to include the QBF. And if not then you may "simply" compare the two projects and find the difference. To recreate the project from the scratch is necessary sometimes but the reason is unknown obviously.