Startup Scripts

[goldberg2727]

I am curious to know what other developers put in their startup scripts for a typical application (not that there is really a typical application). But do you update indexes? Pack tables? every time your app starts or at the beginning of the work day/week/month?

[csda1]

Re: Startup Scripts

Hi Lee,

I am curious to know what other developers put in their startup scripts for a typical application (not that there is really a typical application). But do you update indexes? Pack tables? every time your app starts or at the beginning of the work day/week/month?

Yes.




It can be anything, starting with login screens, initializing variables, opening startup menus. Updating indexes, Packing Tables are generally placed on system maintenance menus as they require exclusive control of the tables.

And in genreral, you should never really need to pack data tables, at least not on a record basis. Data should not normally be deleted, but marked as old and not shown IMHO. This allows a better view at history of the data.

[goldberg2727]

Re: Startup Scripts

I understand that a startup script can be anything....I just was wondering if there is any standard that developers use from application to application where they always include certain functions in a startup script. (i.e. Update Indexes)

[Tom Cone Jr]

Re: Startup Scripts

Lee, I think there may be no "standard", since the needs of each application vary. In general terms most use the startup sequences to initialize variables and set configuration options appropriate to the app. In general most would never automatically re-index or pack tables, for the reasons Ira has already stated. -- tom

[jkletrovets]

Re: Startup Scripts

Lee

To echo what Tom said.....I initialize global variables used throughout my apps, my custom security framework runs and has the user login and then I initialize what menu items will be shown to the user (again from my security framework).

Regards,

Jeff

[csda1]

Re: Startup Scripts

Hi Jeff,

.....I initialize global variables used throughout my apps...

And I hope you took my Global variable recommendation (and addin variables and shared variables) to heart and only have 1, uniquely named, global variable pointer and then place all your variables as properties under that. It will eliminate collisions with other variables that utilize the same name.

[jkletrovets]

Re: Startup Scripts

Well Ira...ummmm.......hmmmmmm..... :)

I actually did not. :o

I guess this may be left over from my Foxpro days but I have a system I follow naming variables that is pretty bullet proof at eliminating conflicts (unless I have a brain fart). :)

I use something like this:

DIM GLOBAL gvsysrefdocpath as C
gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

where gv stands for global variable. ..sys.. means I initialized it as part of the system and then the rest defines what the variable is(in this case a reference document directory).

[csda1]

Re: Startup Scripts

Hi Jeff,

DIM GLOBAL gvsysrefdocpath as C
gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

Isn't it incredible?! I used exactly the same variable name for my reference document path! :D

But I suspect you can see how someone could choose something identical, albeit very unlikely. But if you had done something like

dim global jkletrovets as p
dim global jkletrovets.gvsysrefdocpath as c
jkletrovets.gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

It would almost never be able to compromise it (and if it did, it's just a global change of the pointer's name.

In most of my code, I'll take the global pointer and move it to a local pointer as in

dim global jkletrovets as p
dim ptr as p
dim ptr.gvsysrefdocpath as c
ptr.gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

So ptr is local copy of the global variable pointer, and gvsysrefdocpath is dim'ed as c (and will remain because the global pointer will still exist after the code ends). "ptr" is shorter and will go away after the code ends.

[Louis Nickerson]

Re: Startup Scripts

Ira,

I have followed your postings for years now.

Just read the document you created entitled "CSDA Tips on
Alpha Five &
Product Tips"

It is obvious that you have devoted countless hours to helping others take advantage of this phenominal tool Alpha has created.

Thank you for sharing your knowledge and experience.

Louis

[csda1]

Re: Startup Scripts

Hi Jeff,

Oops!

In most of my code, I'll take the global pointer and move it to a local pointer as in

dim global jkletrovets as p
dim ptr as p
dim ptr.gvsysrefdocpath as c
ptr.gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

So ptr is local copy of the global variable pointer, and gvsysrefdocpath is dim'ed as c (and will remain because the global pointer will still exist after the code ends). "ptr" is shorter and will go away after the code ends.

I meant to say, in most of my code, I'll take the global pointer and copy it to a local pointer as in

dim global jkletrovets as p
dim ptr as p
ptr=jkletrovets
dim ptr.gvsysrefdocpath as c
ptr.gvsysrefdocpath=a5.Get_Path()+"\refdocs\\"

So I will use ptr as a local copy of the global variable pointer, and gvsysrefdocpath is dim'ed as c (and will remain because the global pointer will still exist to the variable space after the code ends). "ptr" is shorter and will go away after the code ends.

Hi Louis,

I'm glad it proves useful and appreciate your thoughts. However, I kindof feel bad, because my tips page started out for selfish reasons :) - I hated repeating myself constantly on the message forum and was often rewording an answer, not always being as clear. Since my tip page is a constantly updated document, it only improves with time, and is a reference for people that is easier to find.

[goldberg2727]

Re: Startup Scripts

Very useful! Thanks Ira! Always opening my eyes to new methods, I appreciate it!

[smartz]

Re: Startup Scripts

Where can I find your list of Tips?

[jkletrovets]

Re: Startup Scripts

Steve

They are here.

Also Cal Locklin's naming conventions are great advice


BTW, interesting stuff in the ptr example above Ira.

Regards,

Jeff