Directory Help

[Tom Patten]

Hi,

I have all my data in one Directory, plus its subdirectory (C:|A5V4|Pals|backup).

I have field rule that references a table lookup that resides in the subdirectory. In setting the path to this subdirecty, is there a way to reference it without using the full path C:|A5V4|Pals|backup?

The problem is that if I want to move the application to another location, although all the files are in the one directory, the lookup continues to search for a specific location - C:|A5V4|Pals|backup. I'd like to be able to drop the A5V4 part of addressing the subdirectory. I seems to me there use to be a dos method for doing this.

Tom

[Ohlen Cartmell]

RE: Directory Help

Tom,
If the directory structure is the same on all computers, won't the program perform the way you want? That is, if the relative position of the folders and the names of the folders and files are the same.

[Geoffrey Hollander]

RE: Directory Help

Thomas,

You'll be relieved to find out that this is easy. Many developers write an application with literal referrences to tables' locations. Once they try to move it to another system's drive or directory structure, they're screwed.

Here is what you can do. Declare your directories as global variables in your autoexec script. First, you should open your application from the [application-name].adb file using a shortcut.

Your autoexec script then can contain some staterments like these:

DIM global HomeDir as C
HomeDir = dir_get()

(This grabs and stores the name of the directory containing your [application-name].adb file.)

You can then add (for your embedded subdirectory):

DIM global WorkDir as C
WorkDir = HomeDir+"backup"

You can, for other purposes, write additional variables pointing to other directories...

When it comes time to state a location, such as in opening a default browse, you can then write:

Browse.View("Default Browse for [table's alias]@HomeDir+'backup[table-name].dbf'")

This assumes that the table is in the backup directory. If the table is in the home directory, this would be written:

Browse.View("Default Browse for [table's alias]@HomeDir+'[table-name].dbf'")

As you can see, you can get pretty creative with the number and variety of variables that you establish and load during startup. Oh, I need to mention that it's important to do this in the autoexec script so that the directory that 'Homedir" loads is always the one from which your application has started up.

Hope this helps.

Regards,

Geoff Hollander

[Tom Patten]

RE: Directory Help

Ohlen,

That the problem - I don't plan on having installed at the same location on all computers. But maybe I should change my plans.

Geoff,

I need to address the table in the backup subdirectory in a field rule, to do a lookup on the table. I'll have to play around with @homeDir+"backup|tablename.dbf") Are there back slashes that this message board dropped?

I'll let you know if I can get it to work.

Tom

[Geoffrey Hollander]

RE: Directory Help

Oops, It looks like that's the case...

Add a bachslash inside the quotes preceeding your subdirectory or table name and, of course, between them.

Geoff

[Tom Patten]

RE: Directory Help

Geoff,

I'm getting close, thanks to you.

But in field rules I cannot get the right syntax. How would you ammend - Browse.View("Default Browse for [table's alias]@HomeDir+'backup[table-name].dbf'") to address a table in field rules lookup. The address is: c:|A5V4|Pals|backup|diagcode.dbf

Thanks much.

Tom

[Finian Lennon]

RE: Directory Help

I think that as Geoff suggested, you need to define one or more global variables in your autoexec or logon scripts. These, in conjunction with manipulation of the shared and private paths should give you all the flexibility you need.

When you place a lookup table in the sub-folder of the A5 program folder, you can identify that string with lookup_path=:A5.Get_Private_Path() and use that value in your path arithmetic. However putting it there adds a significant maintenance overhead to managing and distributing your app. To my way of thinking, external tables not placed directly in the main app sub-folder should be in sub-folders of the main. If the purpose of placing the table in the private path is to allow each user to have their own lookup values, you could achieve the same thing by creating a users sub-folder in the main app folder, and creating a sub-folder for each user.

Finian

[Tom Patten]

RE: Directory Help

Finain,

I have the variable defined and showing correctly.

But how to reference it in field rules lookup?

You say, "To my way of thinking, external tables not placed directly in the main app sub-folder should be in sub-folders of the main." And I do have this folder as a sub-directory of the application.

So how do I address this folder so that field rules will do a lookup on it. C:|A5V4|Pals|diagcode.dbf C:|PALs in the main folder of my application.

Thanks

Tom

[Finian Lennon]

RE: Directory Help

You can define the lookup in field rules but, if the table is not in the main app folder, A5 will hard code the path to that table and will lose it if you move the app to a different location.

Why don't you put the lookup table in the main app folder? It is possible to define lookups via xbasic and it's pretty straightforward to do so in a form, but less so in a browse.

Finian

[Tom Patten]

RE: Directory Help

I don't have it in the main app folder because it is very large and seldom used. Just one form uses it. It is not in a browse. And, if it is not in the main app folder, I can backup all the dbf on a floppy disk.

Another approach would be to define my backup to exclude this file, then I could move it back to the main app folder. I am using a dos .bat file to execute the backup.

Copy c:|A4V4|Pals|*.dbf to a:pals

Do you know how to write a copy bat file to exclude a .dbf? Would a -diagcode.dbf work?

Otherwise I would have to list 25 dbf files. But that is doable if having a sub-directory limits my portability.

Tom

[Tom Cone Jr]

RE: Directory Help

Tom, have you tried adding global variables to the table itself, prior to defining your field rule? (Edit structure of table, select Variables off the Table menu item drop down list.)

Will that give you a persistent variable which you can then reference in your field rule?

-- tom

[Tom Patten]

RE: Directory Help

NOPE!

I works to define a variable equal to the path I want, but in field rules, it will not accept any combination I could think of. It keeps adding ".dbf" to the end.

Thanks to taking a "Wak" at this.

Tom

[Geoffrey Hollander]

RE: Directory Help

Tom,

Bbecause I can't see the code etc. that you're using, I'm going to guess what may be going on. Once you have defined your globals, go into the code editor, use interactive to determine exactly what it(they) is(are) contain(s).

A variable string that works in one area of A5 might not work in another. For example, I don't use the whole path that I showed you when specifying a tbl = table.open() statement in my code. I have a different memory variable setup for those statements. In fact, I load 200-300 different global memory variables every time Scrubber!(my application) starts up. So, if the Field Rules will take your variable, but want to add ".dbf", make a varable that omits it in the contained string and then let A5 add it on.

At other times, when a variable is used with in a set of double quotes, like in a expression, you may have to add extra characters to negate the variable's contained quotes (i.e. "+memory_variable_name+"). This is especially true if it contains a field name. You may also, in certain circumstances, have to put a "var->" in front of it to show A5 to what kind of content you are referring.

It takes some time and experimentation to figure out which alternative (I've only suggested a few possiblities) that will ultimately work.

Hope this helped.

Regards,

Geoff Hollander

[Tom Patten]

RE: Directory Help

Thanks Geoff - I'll experiment a little longer. But I suspect that in field rules, lookup, where there is the file icon, it wants an actual location in the directory tree, not a variable referencing it.

Tom