During 'Run' the form opens, during 'Build' it does not

[sashaDG]

Hello everyone, there is a PageFrame and a button, when clicked, another form opens. During the 'Run' everything works and past exe worked correctly, but when I 'build' the last form opening does not work. There are no errors, I changed the button,the form the situation does not change.

I want to note when everything was working, when starting the EXE, I had to close the Project Manager, because an error appeared. Now there is no error, I can open PM and EXE. I can't even imagine what I could change.

 

[Chris Miller]

What's the code of the button that runs the other form?

I ask, because in the normal case a build of an EXE includes all project files into the EXE, if some form isn't part of the project but code specifies it, it becomes part of the project while you build, so that fixes the problem the second form might not be part of the project "on the go", meaning it adds the form to both the project and the final EXE.

Are you perhaps just editing single files, don't use a project and the project manager, and build an EXE by using the BUILD command? That could mean your second form isn't included in the EXE.

Do things with a project and the project manager and you'll have a better overall experience, if you don't yet do.

If you do use a project, I wonder how you got that going. If you explicitly excluded the second form you will of course not have a working EXE, but then why would you do that?

Chriss

 

[Chris Miller]

Regarding running EXE and Foxpro side by side. That should never be a problem as the EXE uses a vfp9r.dll as runtime, VFP9.exe is its own runtime, no overlap there. The EXE runs its own embedded files, so no project file is locked during EXE execution. VFP usually loads a PJX (project) in exclusive mode (locks the file), but that's not part of the EXE. And VFP doesn't lock any other files. So again, no overlap. And VFP9.exe even uses a separate design time resource DLL vfp9enu.dll, while the EXE or the runtime uses vfp9renu.dll, still no overlap.

What you can't do while an EXE runs is build the next version, as VFP can't replace the EXE when it's currently running. You also can only start an EXE when it's built fully, as VFP9.exe only releases any file handle it has when the EXE is finished. But right then, and before you close VFP, you can run the EXE. In fact, I sometimes start the build process, so I get the file dialog and then start the previously built EXE from that dialog. Even that works, as you didn't yet start the new build.

I guess I don't understand your problem fully, but do you still have a problem compiling a working EXE after a complete restart? You know the usual IT crowd solution. If you have project and it persists to not compile to a working EXE, the first thing you can do is "Clean up project" from the project menu. And if even that fails, create a new empty pjx and add in project files. You can start with the main.prg and build, that may already cause most of the project files to get included into the new pjx, some graphics and things you specify with relative paths or no path may be overlooked. Still, there is not much value in the pjx/pjt files themselves that you can't start from scratch.

Chriss

 

[sashaDG]

The forms are in the Project. "Clean the project" did not understand this point. Tomorrow I'll try to create a PJX file, maybe restarting the computer will have an effect.

 

[Chris Miller]

Clean up project" is a menu item in the VFP project menu:

Chriss

 

[sashaDG]

I cleaned the project, nothing happened except error 1113, then it disappeared.

In the main form WyndowType = 0 - Modeless, in the child form ShowWindow = 0 - In Screen. When I changed the ShowWindow to any other, everything worked.

 

[Chris Miller]

Error 1113, is "File is not open", for those who wonder. I guess the project cleanup had a problem opening one of the project files.

In the end what you tell is not seeing a form at runtime, because it was an "In screen" form. So likely your project has a config.fpw file that has "SCREEN=OFF", maybe from a previous thread recommending that, if you want to establish your own top-level form. (I have searched the form and not found a thread, but maybe you read about it and thought it's good to always have that. No, it's not always a good idea.

Well, but what you see is correct behavior and to be expected.

It's correct: Form s are by default "In screen" and only visible, if the screen, aka the form _SCREEN, is visible. So if that's hidden all forms are hidden. The meaning of "In screen" does not change to "in the main form", when you establish your own top-level main form. There's explicitly another ShowWindow=2 (in top level forms) setting for that. Screen is screen, one any only one, top forms can be many, your own forms and whichever is currently the active top level form becomes the parent form for "in top level" forms and clips it, is the boundary of its moving around.

It's to be expected: In the sense that you see our in screen forms while you program them within VFP. Because VFP itself has the screen visible. You only see the consequence of SCREEN=OFF at runtime, in the EXE.

So you don't just get "that annoying empty form with the menu" hidden, everything is hidden as it's screen or in screen by default. If you decide for SCREEN=OFF you have to be consequential and change all your forms to now be either top level forms, (Show Window=1) or "in top level" (ShowWindow=2).

The normal use case for an application without screen is a single form application. I guess many who see the screen and their form inside don't want it, some may even discover the menu has items only working within VFP itself. But there is a simple alternative to hiding the screen: You can also SET SYSMENU OFF to get rid of the partially non working menu. If you want something else than a single form appliction, it's actually easier to work with the screen as your empty "desktop" and main application menu form, SET SYSMENU OFF and also establish your own menu, maybe also added a toolbar or something fancier as a ribbon. There are VFPX projects making that an easy task.

And in the end, I don't know if you like VFP itself from it's interface, but in itself it's a good example of how an application that has a screen can look. You can configure it to come up with the last project you edited, the property window being shown, the command window, etc. It keeps that states and doesn't come up empty, when you start it. And in your application you can do the same, you can choose to let it be your frame for all of your application, that's populated with menu, a start form, toolbar, ribbon, whatever other side windows as you want. It's up to you to make it less dull.

Chriss