What are the top VFP Nemesis

[jimoo]

I hope to make this a fun topic, but one we can learn from, and because of that, I am asking for this to be a no-star thread.

Here it is.

What is our top VFP Nemesis?

In other words, our top enemies of VFP programming, or things we should not do. Please keep the responses to only VFP programming.

INVALID RESPONSES
COBOL, DOT NET, MAC, LINUX, Etc. - They are not VFP Programming

Valid Responses:
- Hard coding Paths
- Use of .mem files
- Etc...

I can name 10 myself, but I don't just want my thoughts, but a group effort.

I'll start it out with my 1st, but it may not even make our group top 10 (or so) list. Again, a group reply.

My #1 is:
"Hard coded paths"

Also, if they are good - please let the person know that is a good one. A reply is sufficient.


If we have good success, I'll make this into a FAQ (credit the group) for the top 10 things to avoid.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[ramani]

HI

When you develop a programme, I would say what you should do, rather than what you should not.

1. Think Big... Think that it will become an International multi language pack. Think well (project planning) before you start to proceed with work. (Invariably it is the concepts of what is to be written that is important to me. - Here the degree will vary from person to person. I believe anything required can be met. So I dont think, how to make that work. I think what is to be worked and that is important to me.)

2. Think Multiuser concept. SO paths, Data files locations, backups, restorations etc well founded.
Imagine your application will be used by 1000s of users from a single server!

3. Think of web possibility, so any one from anywhere can work on the application.

4. Provide #INCLUDE myHeader.H and use this reference frequently in all your codes. (This will help modify packages fast as you roll future versions.) Also as much possible, be 'native VFP' so as versions progress we dont say.. "now that functionality will not work".

5. Use TRANSACTION processing to protect again failures. See next step and that is where I code TRANSACTION PROCESSING. (it will be found in only one place in my entire application).

6. I suggest always, make the ultimate writing to data files in hard disk thru a unified function. This has a big advantage to manipulate server or hardware oriented calls.
So when I want two different places to update..
I just reach the writing routine.. do a change..
** Write to harddiska#1
If success
** Write to harddiska#1
ELSE
** report and ask for restore help whatever
ENDIF
This can be made triplicate also for mission critical applications (though I have'nt written anything like that). But as usual think big!, so when day comes you can scale it up quickly.

7. Provide for reusability of code as much as possible. So number of levels to inherit so that easy modifications in n-tier type can be done.

8. It is imperitive that error handling is done well so that, as and when it occurs, it should not be lost by user pressing OK - enter. This should be captured and possibly emailed immediately with suitable heading and information to you the developer or captured and kept in a log file or both. Never take this .. 'let us see when it occurs next time..'. Try to identify and solve it early to avoid complications.

9. Use extensive details in your code - that is remarks so that we can get back on to job quickly.

10. Do effective backup as you proceed with the development work.

May be I am starting counter to Jim (that is not my intenstion), but I will struggle to put these the other way. The reverse is what Jim wants in this thread and any one can figure that out.



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

When you ask VFP questions, please add VFP version.

 

[alvechurchdata]

Can't think of ten quickly - here's a few:

1. Learn to type accurately. If you mistype the name of a boolean then Fox will cheerfully create that new name and initialise it to .F.

2. Use a naming convention so as you don't get clashes between memvars and fields.

3. Don't use Public. If you have to use a global then declare it Private at top level. It makes no difference in the run-time but Publics persist in the development environment.

4. Run debug as a separate process. Ever so useful when your app locks up during a test.

5. Don't over OOPify. There's nothing wrong with a procedure file.

6. Keep field names down to ten characters. That way the field can have the same name as its index.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Hmm. Judging by the two replies so far, this thread seems to have become "Top tips for VFP", which I think is the opposite of what Jim intended (but they are still valid contritbutions, of course).

My choice of nemesis would be:

- Lack of comments. I'm always amazed how many experienced programmers haven't twigged to the idea of commenting their code.

- Over-reliance on public variables (especially creating public variables on the fly at arbitrary points in the app).

By the way, welcome to the forum, Geoff. I see you just joined in the last couple of days. Quite a few of our pals from MSDEVEAPPS have passed this way, and a few have sutck around. I hope you do too.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[jimoo]

Ramami's point is good. Things we should work to achieve, but there are also some habits I think there are some things we can try to avoid.

Mike is right on with my intention. Here are a few more of mine.

- Poor and/or non-standard directory structures
Keep them something like this, and reference them with a path or project.

Data
progs
reports
forms
etc.

Too often I see them thrown in one or two directories.

- Non-movable apps. They reply on the current directory structure, usually because of hard coded paths.

- Forms that you cannot run with out cntl-e. I try to design all my forms so I can run them independently. This is great for development / testing and you don't lose the debug window.

- Excessive use of colors.

- Reports that automatically go to print (unless it is a batch print job) and don't give you the option of preview.

- Excessive use of public variable

- CLEAR ALL in code (unless I am exiting the program).

I have more, but those are some starters.




Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[AirCon]

I just want to add one thing (related to public variable).

- Form as Main project. We can avoid using public variable if we use PRG for the main project.


Jim,
CLEAR ALL in code (unless I am exiting the program)

I'm not sure I get your real point. But this is my comment.

Yes we should avoid using it in the project. It could leads to fatal error if we issue in the middle of application.

Under development/testing some examples, I use this regularly. Why? I want to make sure that VFP environment is "clean" before run another samples/tester program, especially when dealing with Objects, Bitmap/Other resources, DLLs. I always issue this command at the end of every samples/tester program. Sometimes CLEAR ALL itself is not clean enough for me. So I use macro (F10) to issue this:
CLOSE ALL
CLEAR DLLS
CLEAR ALL
CLEAR PROGRAM
CLEAR RESOURCES

Also, thank you for bringing up this subject. Now I understand what was happening on my FAQ thread (never thought it could happened). I should not make any assumptions for any conditions (Ughhh.. )


-- AirCon --

 

[jimoo]

In development, I use those commands myself.

The problem I have with CLEAR ALL is that I have inherited systems where the original developer issues that command in a sub-program. Needless to say, that blows away everything I have setup.

It's not only clear all though, it's the issuing of SET PROCEDURE TO without anything. Thus, clearing our program library.

I guess what I am trying to say is set the environment back to how you had it when you entered the program.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[AirCon]

Ahh..I see. Agree with it

-- AirCon --

 

[jimstarr]

My top VFP Nemesis? Nested IIF's!! -Jim

 

[craigsboyd]

According to the "Hacker's Guide to Visual Foxpro 7.0" (I agree with some of their assertions and their reasoning is sound for most)

Commands to Never Use:
[ol][li]Accept[/li]
[li]Input[/li]
[li]Define Box[/li]
[li]Insert[/li]
[li]Join[/li]
[li]Set Compatible On[/li]
[li]Set DoHistory On[/li]
[li]Sort[/li]
[li]Sys(12), Sys(23), Sys(24), Sys(1001)[/li]
[li]Update[/li][/ol]

Commands for Development Use Only:
[ol][li]Validate Database Recover[/li]
[li]Append[/li]
[li]Browse/Edit/Change[/li]
[li]Create[/li]
[li]Find[/li]
[li]Modify Structure[/li][/ol]

Commands to Use with Extreme Caution:
[ol][li]Zap[/li]
[li]Pack[/li][/ol]

Slighthaze = NULL
[sub]craig1442@mchsi.com[/sub][sup]

"Whom computers would destroy, they must first drive mad." - Anon​

[/sup]

 

[jimoo]

Interesing, but if you should never use "insert" and only use append in development, how do they expect you to add a new record in your application?

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[Mike Gagnon]

jimoo

I believe that the Hacker's guide is refering the original insert (Which has been replace by Append or Insert - SQL), which is maintained for backward compatibility.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[craigsboyd]

jimoo,

Sorry for any confusion. The INSERT command spoken of above is not to be confused with "INSERT - SQL command". INSERT is only still included in VFP for Backward Compatibility. What it does is insert a record between two other records in a table (physical order)...which forces VFP to rewrite the remainder of the table. There are lots of better ways to order a table should you need a record to appear in a particular spot...a well thought out index or an SQL to a cursor come to mind. Relying on the physical order of a table is hardly if ever a good idea.

The APPEND command is meant as just that "APPEND", not Append Blank etc. and is not a good way to allow the user to enter data. The window it brings up (CHANGE) while an interface that a developer may find useful, is certainly not a good USER interface.

Slighthaze = NULL
[sub]craig1442@mchsi.com[/sub][sup]

"Whom computers would destroy, they must first drive mad." - Anon​

[/sup]

 

[torturedmind]

My top nemesis of VFP: forgetting the BASICS - most programmer (in general) tend to forget how things can be done using the basic and simplest form of codes.

kilroy

 

[jimoo]

Slighthaze

Thanks - How quickly we forget. I have been around the xbase arena since DBASE III+, then Clipper, then fox 2x. You would have thought I would have remembered that



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[Mike Lewis]

Commands to Use with Extreme Caution:
Zap
Pack

Disagree. If you build a cursor with temporary data (for a report, say), then want to clear it out to do another report or whatever, Zap is the easiest and fastest way of doing so, and perfectly safe (since it is temporary data you are dealing with).

Pack is also safe in the sense that it will only delete records which have already been deleted (if you see what I mean).

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[craigsboyd]

MikeLewis,

Very good points.

Regarding ZAP: the book does point out the command's place for removing all the records from a temporary cursor, especially for a cursor bound to a grid (one of the places I use it the most frequently). I would however add that I try to remember to always include the [IN nWorkArea | cTableAlias] parameter when using it in this fashion on the off chance (due to an error or miscalculation somewhere) the current work area is not the one it should be. With ZAP I have no undo, there is only my trust and prayers that the user had the foresight to actually backup their data on a regular basis if something goes wrong.

Another thing that I try to keep in mind when using ZAP is that it does not cause the Delete Trigger to occur (if there is one). ZAP is faster and indeed different than issuing a DELETE ALL followed by a PACK.

Regarding PACK: there does appear to exist a tiny window of opportunity for something bad to happen. The order in which VFP does thing during a pack is as follows.
[ol][li]Copy all non-deleted records to a new table[/li]
[li]Rename the original table to something different[/li]
[li]Rename the new table to the original name[/li]
[li]Erase the original table[/li]
[li]Put the backlink info into the new table's header (if the original table belonged to a DBC)[/li][/ol]
...if your application, or the computer it was running on, was to shut down irregulary or hang between steps 1 and 2 then you would end up without any table/file that had the original name any longer. In effect that table would now be missing. The book does point out that the chances of this are extremely slim given the tiny window of opportunity.

As for me, I use both ZAP and PACK when I feel that the situation warrants it, as well as a couple of other commands that they have on their list. So I agree with you Mike, and I also think that what is or can be construed as a VFP Nemesis has a lot to do with the knowledge and experience of the developer.




Slighthaze = NULL
[sub]craig1442@mchsi.com[/sub][sup]

"Whom computers would destroy, they must first drive mad." - Anon​

[/sup]

 

[ramani]

Hi

The DELETE ALL command is tricky too like the ZAP.

I once faced a tricky situation. The NIC was in fault.

SO when the user tried to access a table, the NIC denied the access and the ON ERROR quietly gave the message and returned back. (The error routine only quits the event, while the rest of the code called from another event continues.)

As a result, the following code continues executing. The assumed default alias were not present .. and some how.. the application showed OPEN TABLE window to enable the user to select a file to open. The user presses an enter key there by slecting the first table in the window. The following DELETE ALL command deleted all the records with associated recursive actions. You can imagine the problem.

However, I could not trace the bug in my code for quite some time, until the NICs failure became more pronounced and my reviewing the code for a DELETE ALL confirmed it.

That time onwards, I use
DELETE ALL IN cAlias
though I might very well be in the default alias itself.




____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

When you ask VFP questions, please add VFP version.

 

[EzLogic]

Not Using our own classes for Labels, TextBoxes, and other controls that we use alot to build an app.

I learned the hardway. And i think many 'new' vfp programmers like myself do the same thing. they simply drag and drop the controls on the form.

Then, i found out how hard it is to change, say, the font or color, or even some behavior throughout my app.

but, by simply making a new class, you can change it once, and bam, it is changed all over, Still, you can override your changes for 1 instance if you wish.



Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan

 

[jimoo]

I'll throw one in, that may not be popular with the group, but I don't like to use a lot of the VFP sample classes. Take the movers, for example, once you add one simple mover it brings a lot into your project and the exe is greatly enhanced. Over time, I have used the mover class to see how it was done, studied it, but use my own classes that are tight code and I thoroughly understand.

I guess my statement is:
Don't get VFP sample class carried away. Use them case by case.



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com