Even if we can't include all the files in the base image, we can sometimes include some of the larger files that we would otherwise have to download, and we can also sometimes remove the most time-consuming steps. This can help a lot with reducing deployment times.
Solved
QBF object disappearing from forms after building exe in VFP 9
Posted on 2013-01-25
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.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
6-
6
5
17 Comments
Active today
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.
Active today
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.
Active today
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.
Active today
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.
Active today
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.
Active today
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
Active today
CLEAR ALL is even more "destructive" command than CLOSE ALL. CLEAR ALL releases all variables and all pending and inactive objects and more. It is more reset than cleanup... You have to set your environment up after the CLEAR ALL obviously.
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.
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.
Active today
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.
Active today
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?
Featured Post
Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Microsoft Visual FoxPro (short VFP) is a programming language with it’s own IDE and database, ranking somewhat between Access and VB.NET + SQL Server (Express).
Product Description: http://msdn.microsoft.com/en-us/vfoxpro/default.aspx (http://msd…
Experts give $3,000 toward hurricane relief efforts—but that's not all!
In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment.
To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data.
But that feeling is fleeting. Attacks these days can happen in many w…
Suggested Courses
Course of the Month5 days, 6 hours left to enroll
671 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.