settings in config.fpw

[EinTerraner]

How can i set a different filename for the "_command.prg" like i can do it with the ressourcefile shown below.

the ressource i can set in the config.fpw with

_include = .\@defines.h
Default = .\
screen=on
toolbars=on
TOOLTIP = 1
sysformats = on
title = VisualFoxPro    F V N 2 4
progwork = .\
resource = c:\$dev\temps\FVN24.dbf
path = .\;..\@lib21;..\@com;..\@com\ICON;.\FORMS;.\CLASS;.\FVLIB
command = _screen.WindowState = 2

and 2nd question: Sometimes Fox forget the last docking-settings for the property, command and datasession-windows. how can i disable the "Dockable"-switch on startup?

 

[Chris Miller]

_command.prg is the save file for the history of commands typed into the command window. The file name for that is always _command.prg. It also is always stored into the same directory as the foxuser.dbf resource file.

With SET RESOURCE or the RESOURCE = ... line in a config.fpw you have the means to change to another name than foxuser.dbf, that's true, but since the _command.prg is just bound to the directory of the foxuser (or in your case the FVN24) files, it's name has no setting you can configure. Not that I know.

So if you want to be able to swich between several save states of the command window, you'll need to rename whichever file you want to be the active _command.prg for a session before starting a new vfp9.exe process that reads that prg into the command window. Otherwise your options are obviously different directories for the resource files to switch the corresponding _command.prg, they only come as a pair in the same directory. Also, the _command.prg is only read in at VFP IDE start and saved when closing, while the environment manager allows to switch many settings including the resource file, switching environments won't switch to another command window history _command.prg, too. So that only applies to restarting VFP.

It's not impossible to let VFP restart itself by RUN /N vfp9.exe followed by QUIT. The new VFP9.exe process and the current VFP9.exe process will compete about file handles to foxuser and _command.prg and maybe even ome more files. To avoid that maybe write out a vfpstart.cmd file that waits 100ms before starting VFP9.exe again and the RUN /N startvfp.cmd and QUIT, so the QUIT can write out changes to foxuser.dbf and _command.prg and close all file handles before the next vfp9.exe process starts.

I think before you go into that, you should take a look at the environment manager and the options it gives you when switching environments and/or projects.

 

[Chris Miller]

2nd question: Sometimes Fox forget the last docking-settings for the property, command and datasession-windows. how can i disable the "Dockable"-switch on startup?

As far as I know it's an unresolved flaw of VFP to reproduce the states of the IDE windows especially the docking. An obvious workaround is writing a PRG you set as COMMAND = DO idestart.prg and make all necessary steps to position and dock or undock IDE windows there.

 

[Mike Lewis]

As far as I know it's an unresolved flaw of VFP to reproduce the states of the IDE windows especially the docking.

That's not my experience. I have the four system windows (Command, Document View, Properties and Data Session) all set to Dockable and Docked. Those settings are always retained between sessions. The only exception is if I need to start VFP with a different resource file, but in general there is no reason to do that.

Mike

 

[Chris Miller]

I just use "Window->Arrange All" and have what's open side by side, if at all. For that to work flawless every window has to have dockable unchecked. If I like one window at a different place than the automatism decided, that's simple enough by just moving a window slightly off place and repeating "Arrange All".

 

[Paul Gibson]

Regarding the positioning of the window elements in the VFP IDE (Data Session, Command Window, Document View, Properties), I also like those elements to remain in very specific places which suit my habits and as others have said, the IDE will remember where you left them when you closed the IDE, given the resource file is consistent. However, on occasion this can get messed up, but in my experience it is always in a fairly specific scenario and thankfully very rare.

To my mind, the only issue I ever have with the windows not appearing in the correct location is after a major crash that has almost always been my fault. I'll elaborate.

For example, I'm testing my application "in development" i.e. running it in the IDE rather than compiling it and running the exe, but I've made some mistake in the area I'm testing that puts the application and therefore the IDE in such a bad way that it's quicker and easier to just bomb out of the IDE brutally, rather than trying to recover gracefully.

In that scenario, when I reload the IDE, there is a good chance that one or more elements (usually the command window) has changed in a couple of ways.

1. The window is sitting in the top right corner of the IDE instead of the location I like to have it.
2. The dockable setting has reverted back to On, when I always have it set to off

To help with some of this, I have the startup.app that my IDE runs, call a TidyVfpWindow program that I wrote, which simply moves each window to the location that I like it to be. That way, the windows should always be in my preferred location regardless. That was the intention, there is still one exception though.

The only thing I haven't solved is #2 above. When my TidyVfpWindow program runs, it appears to have no effect on Windows where the dockable setting is On and I don't know if it is possible to programmatically set it off.

I don't get too frustrated with this, I accept that it is my penance for making a mistake which ultimately resulted in me having to bomb out of the IDE, I manually switch dockable off and call my startup app again which repositions everything and results in all the elements being as I like again.

 

[Chris Miller]

I'd like to hear in more detail what EinTerraner expects or wants.

One thing you can do yourself, in the aspect of switching the command window content is activating the command window and deleting all its content with CTRL+A and DEL with KEYBOARD commands and pasting in what you read from another command.prg file.

The aspect I would guess is leading to the demand to use multiple resource files and command window history is to have everything individually ideal for each project you work on. And one thing that you don't have with mujltiple resource files is a central place to store the states of IDE windows. So if you want to change something generally in all projects, you have to merge that into your 3,4,5,6,... whatever number of different foxuser.dbf resource files. Working with environments also doesn't change that, but environments offer a lot of features worth using them to easily switch between projects and have necessary settings, quit or start certain application frameworks integrating into the IDE, etc. One major option you have is two scripts that execute before you switch to an environment and after, so before and after hooks.

But what do you do when you want to centralize something? In the OOP world you centralize something in a root class everything else inherits from. Separate foxuser.dbfs don't inherit from a root foxuser.dbf, that's not how data works It's also questionable to establish this with other means, like having a set of records central and overriding individual resource file records, if in many cases your individual resource files should allow overriding the central settings, insteqad of vice versa. That becomes a problem of the type you can't eat the cake and keep it.

Regarding programmatically setting the dockable state of IDE windows, I think the answer is in the binary content of some foxuser.dbf records, the difference of a record for an IDE once in a docakable state and once non dockable should reveal which bit of that binary bytes is the dockable flag.