File Choosing Manipulation (Conceptual Design) 1

[Scott24x7]

Hi All,
So I've reached an important stage in the build of my application, one that I've been putting off for a while, because I knew it would be a bit complex, potentially messy, but I thought I would seek the guidance of the Tek-Tips community on this subject, as I am sure others have done this kind of thing before.

Let me start off by mentioning that, years ago, after a great deal of experience in OLE embedding (especially graphical items, though these days I have a lot bigger issues), found that Fox tables were exceedingly subject to corruption. So that issue still sits with me. I spent months working with tables that had embedded image data into General fields and they just corrupted all the time. Particularly if you were moving the files around.

I eventually went to a linked model using Memo fields to contain the path and file name to a file saved in the working directory. That meant copying the file into the directory first and then "Picking" the file (image only) data which it would just embed the path to the file (which were all saved under the \<application Name>\Graphics\<source of image>\<Filename.ext>

As I am now planning to associate "lose documents" with various sources within the database (and I mean that) I want a new strategy.

The idea is to "pick" the filename from where ever it sits (assuming regular directory navigations, or networked drives, etc) and when the file name is "Picked" it's actually copied into a single directory which will be: \<Application>\DOCUMENTS.

Since I just need a "container" for documents that will get referenced by Memo field as a linked object, I don't really care that they are "cleanly" grouped into different directories. I understand there could be conflict between matching file names, but for now I don't want to manage those in the application, I will force users to make the name unique at the time they select it for including if it already exists.

The question is... how to best go about this process? I'm open to someone's "library" if they have such a thing, or 90% solution where the codes is still open to modification so I could tailor it. I'm also fully willing to write the full thing, but some of that manipulation (especially the "copy a file from one place to another, and then link the directory/filename to Memo file" seems a bit sketchy. (Lot's of FOPEN() calls...)

Is there an elegant solution to this?
Suggestions?
Is ok to tell me to go figure it out myself. Just hoping to cut my development time and learn curve as much as possible.
Thanks to you all in advance.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

What I typically do to avoid expressions like SYS(16,0) in source code is creating an application object property, eg goApp.ApplicationDir = ADDBS(JUSTPATH(SYS(16,0))).
Sure, that does not help with the discovery of functions and their meaning via intellisense. Some numbers stick in your mind like CHR(13)+CHR(10).

Such things can also be solved by constants, like vb does with vbCRLF. We have some definitions in foxpro.h, though it does not even contain CRLF. Indeed such names make code more readable and understandable. You could really #DEFINE EXECUTABLE SYS(16,0) and use the constant name instead of the call, VFP has no limitation to just define some value type like a string, int, date or anything as constant, you can also define calls. The problematic part is, if it collides with variable names or even reserved words, you can even redefine functions, eg you can do bad things with this:

#DEFINE FILE MESSAGEBOX
? File("C:\autoexec.bat")

But also nice things:

#DEFINE FindFirstFile Sys(2000,lcFileSkeleton)
#DEFINE FindNextFile Sys(2000,lcFileSkeleton,1)

lcFileSkeleton = "*fox*"
lcFile = FindFirstFile
Do While !Empty(lcFile)
  ? lcFile
  lcFile = FindNextFile
EndDo

As you can se that has some downsides, th function call has no () - you also can't define constant names with () in them - A function defintion would of course be possible, but then adds to the execution stack level. The bigger disadvantage is, that you nned to predefine variables used as parameter, so whenever using the FindFirstFile or FindNextFile constants a variable lcFileskeleton has to be defined and preset and that's not obvious. If you put definitions in header files that disadvantage can puzzle developers coming into a project later, or even yourself, so in this case I only use it with the #Define embedded right into the code to make obvious where it comes from.

Bye, Olaf.

 

[Scott24x7]

Thanks Olaf, yeah I remember most of these gotcha's about #Define from the past, or other reassignment of calls. So I have always avoided them, and "intuitively" continue to do so.

I never even use #Define, opting instead for variable with macro substitution, just so I can avoid that kind of thing. I think Macro-sub may be a little slower at execution, and if I had a highly intensive routine, I might rethink that, but these days the hardware is so good, I tend not to worry over it like I did in 1994.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Well, wrong conclusion.

The simple constant definitions are very helpful to make code better readable, eg

CursorSetProp("Buffering",5,0)

versus

#DEFINE OPTIMISTIC_TABLEBUFFERING 5
#DEFINE ALL_FUTURE_CURSORS 0

CursorSetProp("Buffering", OPTIMISTIC_TABLEBUFFERING, ALL_FUTURE_CURSORS)

Bye, Olaf.

 

[Dan Freeman]

The simple constant definitions are very helpful to make code better readable

Yes, and no. In unskilled hands they can actually create chaos.

It takes some discipline to use them consistently, too. The code I'm currently working with has been through many hands with varying levels of competence and consistency. A recent change seemed easy at first because I only needed to change one constant and recompile. Then I started discovering all the places where the constant should have been used but wasn't.

 

[Olaf Doschke]

I know what you mean. And I often enough also don't use a central definition, but in place #Defines, even if always the same. It doesn't spare maintenance developers to use referential integrity or other project search tools to find places to change, and still it's easier to find places of OPTIMISTIC_TABLEBUFFERING than 5s.

Bye, Olaf.