Installer question

[CALocklin]

Re: Installer question

Hi Pete,

I think I have seen some expression that identifies the application's root directory in Windows regardless of where the application is installed... it is similar to the alias function under Alpha. A developer really needs to know and work with this expression if the user installs in a directory other than the default.

Kind regards,
Gordon

My suggestion (i.e., what I do) is to create a routine in your autoexec to add the "data" location to the registry. Then set up Astrum to read that value from the registry when installing updates.

I believe I've posted something like this before:
[code]DIM datapath as C
IF a5.Get_Master_Path() = ""
datapath = a5.Get_Path()+chr(92)
ELSE

Company_name = "<MyCompanyName>"

[CALocklin]

Re: Installer question

Hi Pete,

I think I have seen some expression that identifies the application's root directory in Windows regardless of where the application is installed... it is similar to the alias function under Alpha. A developer really needs to know and work with this expression if the user installs in a directory other than the default.

Kind regards,
Gordon

My suggestion (i.e., what I do) is to create a routine in your autoexec to add the "data" location to the registry. Then set up Astrum to read that value from the registry when installing updates.

I believe I've posted something like this before:

DIM datapath as C
IF a5.Get_Master_Path() = ""
    datapath = a5.Get_Path()+chr(92)
ELSE
    datapath = A5.Get_Master_Path() + chr(92)
ENDIF
Company_name = "<MyCompanyName>"
appname = file.filename_parse(a5.Get_Name(),"N")
Registry.sys_create("HKEY_CURRENT_USER\Software" + chr(92) + Company_name + chr(92) + appname + "\DataPath", datapath)

Now just have Astrum look for that registry entry to determine where to install the update files - even from a workstation. (My assumption here is that you do not need to re-install the runtime.)

[GordonMac]

Re: Installer question

Are you sure you got it after installing your test app or did you get it after removing your test app?

There is a very important difference here. If your application install includes an install of the runtime, those .dll files that you install might be getting registered. Guess what happens if you then delete them - they're still registered but they ain't there for Windows to find!

When a file is registered, THAT file is registered - not just any file on the computer that happens to have the same name. So, if you run a test install of an application that includes a runtime install then delete that test install, you will have to re-register the files that were in your "regular" A5 exe folder. That could be called a Windows issue but I think it's more like "between the keyboard and chair" issue. I know because I've done it too - even with Astrum! (Isn't experience a great teacher.)

Hi Cal,

Thanks for the valued commentary. Now that I think of it, you may be correct. I didn't have these issues running a runtime install on the same computer using Alpha 5 V8. However, what you say makes good sense. One of the things that Dave Mason does that seems to automatically correct this condition is to have the following four A5 'dll' files re-registered every time he loads and runs either his A5 runtime or his A5 development platform.

a5controls.dll
a5contexteval.dll
SimpleChart4Lite.dll
Codejock.PropertyGrid.v11.1.3.ocx

That seems to keep the issue in order but really should be done internally by the A5 engine every time it loads. Most people will be testing their runtime on the same machine that they developed their A5 application.

Kind regards,
Gordon

[GordonMac]

Re: Installer question

My suggestion (i.e., what I do) is to create a routine in your autoexec to add the "data" location to the registry. Then set up Astrum to read that value from the registry when installing updates.

I believe I've posted something like this before:
[code]DIM datapath as C
IF a5.Get_Master_Path() = ""
datapath = a5.Get_Path()+chr(92)
ELSE

Company_name = "<MyCompanyName>"

Hi Cal,

Thanks again for the help. Yesterday I finally found what I needed to do within Alpha 5 for setting up aliases so that regardless what directory the user installs to, all my files are located. Here is the code I used within the aliases setup under the A5 'Settings':

[exe_folder] =a5.get_exe_path()+"\\"
[archive] =a5.get_path()+"\archive\\"
[app_folder] =a5.get_path()+"\\"
[table_archive] =a5.get_path()+"\Table Archive\\"
[ezlogobmp] =a5.get_private_path()+"\EZTaskBMP\EZTaskMaster 3\\"

I used both the a5.get_exe_path(); a5.get_path(); as well as the a5.get_private_path() functions to assign locations for my aliases and everything works perfectly. I use a commercial logo indentifying the installed version of the app on many of my forms. With different versions of my application the correct logo needs to display on every form. In order to do that I now only need to change the alias location so that the correct bitmap logo for that version is displayed on every form. It is the only way to go.

Kind regards,
Gordon
SCS

[GordonMac]

Re: Installer question

My suggestion (i.e., what I do) is to create a routine in your autoexec to add the "data" location to the registry. Then set up Astrum to read that value from the registry when installing updates.

I believe I've posted something like this before:

DIM datapath as C
IF a5.Get_Master_Path() = ""
    datapath = a5.Get_Path()+chr(92)
ELSE
    datapath = A5.Get_Master_Path() + chr(92)
ENDIF
Company_name = "<MyCompanyName>"
appname = file.filename_parse(a5.Get_Name(),"N")
Registry.sys_create("HKEY_CURRENT_USER\Software" + chr(92) + Company_name + chr(92) + appname + "\DataPath", datapath)

Now just have Astrum look for that registry entry to determine where to install the update files - even from a workstation. (My assumption here is that you do not need to re-install the runtime.)

Hi Cal,

I copied and saved this valuable autoexec routine since it addresses a different issue which will be comng up for me. From what I understand this is a slick way of registering the datapath, company name, and application name within the Windows Registry so that those values can be found by Astrum, or any other installer, for updating application files. Is that correct?

What difference does it make whether or not you need to update or reinstall the runtime? Astrum can read the information in the registry and still update or reinstall the runtime (providing it is in the same directory as the application files). Correct?

Also, what is the reason for saving the company name and application name, other than for visual identification? I have already created a password protected adminisitration table/form within my application for registering all the logon users, their names, addresses, and company so that every form and document is personalized according to the user that is logged on to that workstation.

Kind regards,
Gordon
SCS

[DaveM]

Re: Installer question

So if one of my buyers happens to have A5 on his machine already, are we saying that we can't safely install an A5 app without wrecking his existing systems ? And would the same problems arise if he already had another A5 runtime app on his PC ?

A couple of years ago, I sent an app to another alpha user for testing something with a complete install including registry entries. It did mess their other alpha v5 apps up, because the settings they had were not the same as mine. Now, if I send something to another Alpha user, it comes with a warning or no reg entries.

In every case so far where I have sold a copy, the people did not have any alpha products, so it is kind of a moot point for me.

.

[CALocklin]

Re: Installer question

... Most people will be testing their runtime on the same machine that they developed their A5 application.

Yep. And I've discovered that this can be a very bad idea. Far too often something will work on your machine but not on the user's machine because of something else that is already set up in your machine.

I went out and bought a used computer for $75 and use it as my "clean machine". I use it only to test install routines. Every time I finish a test I remove all files and folders and then run a System Restore to a previously saved "Clean Time".

I keep wondering if I couldn't just do a full registry dump and restore that to save time over running the system restore. Anybody know?

[CALocklin]

Re: Installer question

From what I understand this is a slick way of registering the datapath, company name, and application name within the Windows Registry so that those values can be found by Astrum, or any other installer, for updating application files. Is that correct?

What I posted will really only save the "datapath" but the others could easily be added. The Company Name and Application Name are only used as keys - not 'values'. I don't believe a key is easy to retrieve.

What difference does it make whether or not you need to update or reinstall the runtime? Astrum can read the information in the registry and still update or reinstall the runtime (providing it is in the same directory as the application files). Correct?

True. But there's a big difference between updating the application and updating the runtime IF they are in different folders. Mine are always in different folders.

If I do a full "install", then I will install the runtime in the runtime folder and the application is installed in a subfolder of that. So, for a full REinstall, I need to get the A5 location from the registry. For a new install it just installs to whatever default location I've defined since it probably won't be able to find the location of an A5 program that doesn't exist yet. For an update, I only install the application files so then I need the "datapath" that my app saved in the registry. (On my own machine, the A5 program is on the D: drive and the development versions of the applications are on the E: drive but that's another story because I don't run the same install/update routines on those.)

My update routines are nearly the same as my install routines except they don't include the runtime because the runtime files seldom need to be updated for users and having them makes the update file MUCH larger. They also don't include the original data files but if I've added any new .dbf files since the original release, they are all in my updates.

All of my install/update routines have the data files (which I keep in a separate group) defined as "never overwrite" - that way I can leave them in the routines so anyone who hasn't updated yet, or who has installed an old backup that didn't have the files (rare but it did happen once), will get the new files and, at the same time, I don't have to worry about someone accidentally overwriting their existing data.

FWIW: Some of my update routines (remember - they install to the application folder which is NOT the same as the A5 folder for my apps) also install and register those .dll and .ocx files just in case. To do that in Astrum, you have to create a variable like <A5v9Exe> and tell Astrum to get the value of that variable from the registry. Then the files are installed to <A5v9Exe> instead of <InstallDir>.
Reg Location: HKCU\Software\Alpha Software\Alpha Five 9.0\ExeLocation\ExeLocation

Also, what is the reason for saving the company name and application name, other than for visual identification? I have already created a password protected adminisitration table/form within my application for registering all the logon users, their names, addresses, and company so that every form and document is personalized according to the user that is logged on to that workstation.

As noted above, I'm not really saving the Company Name or Adb Name - they are only the names of the registry keys (folders) so I know where to find the "datapath" value. Some of my users have multiple apps so all their apps are under my Company Name key and each app has its own key under that. Within each app key is a "datapath" value.

[DaveM]

Re: Installer question

I keep wondering if I couldn't just do a full registry dump and restore that to save time over running the system restore. Anybody know?

I believe what you are doing is probably the most effective and no errors should occur. Time, probably the dump would be quicker. Restore will be with no mistakes.

You could just save the registry and use the saved reg files to overwrite each time. That could save time.

Note: I differ from Cal in that the runtime files and the app are in the same folder. The server part is always in a different folder with no runtime there. I do not run the runtime install on a users's machine. I send the runtime and app for the user in one install package(astrum) with the registry entries and the server portion is in a different install package(astrum) that either installs or updates the server portion. I do this even if the whole thing is going on one computer except in a few cases.

I went out and bought a used computer for $75 and use it as my "clean machine". I use it only to test install routines. Every time I finish a test I remove all files and folders and then run a System Restore to a previously saved "Clean Time".

It takes 2 computers to test my setups and I can install into any folders just like the user can, so the testing is better. That's my way, other differ drastically, but work. One thing in common is it has to have an app and the runtime.

Edit: I forgot to mention, my bootstrap app has code to register the dll's that always seem to have a problem. That way, if I developed it in folder "myapp" and the user decided he wanted it in "hisapp", the dll's are still registered to the user's location.

Mine is not perfect, but it works and I have borrowed heavily from people like Cal.

.

[CALocklin]

Re: Installer question

First a correction of something I posted above. Since my apps are being installed with the runtime, I don't look for the ExeLocation as posted above. I look for the RTExeLocation:
HKey_Current_User\Software\Alpha Software\Alpha Five 9.0\RTExeLocation\RTExeLocation

I send the runtime and app for the user in one install package(astrum)

First, just so nobody gets the wrong idea, I have no issue with installing both in one folder as Dave does. I don't do it because some of my customers have two apps and it would get really confusing with both in one folder. It would work; it's just more confusing. So, just to avoid having either two copies of A5 on one computer or two apps in one folder, I put the apps in a subfolder under the A5 runtime. This is strictly a matter of preference and/or the situation. Either method works. (This reminds me of something else - see below for another developer hint.)

In case anyone assumes that my method requires two install packages because they are in separate folders, it doesn't. Even though I have them in two folders, the fact that the app is in a subfolder means that it's still easy to install them both with one install package AND allow the user to change the location of the runtime folder. The runtime goes in the <InstallDir> folder - which I allow the user to change - and the application goes in the <InstallDir>\AppName folder.

For those not familiar with Astrum, the variables in Astrum are always enclosed in brackets so <InstallDir> is actually a variable name. In this particular case, <InstallDir> can be either 'hard coded', retrieved from the registry, retrieved from a text file (although that probably doesn't make much sense for this particular variable), or the user can (optionally) be allowed to select it.

The ability for Astrum to get the <InstallDir> from the registry is what makes my routine posted above so useful. No matter which workstation you're at, the update routine can still find the "real" data based on the "datapath" stored in the registry. This way there is no need to be on the server in order to install an update. So, my 'update' routine requires that the "datapath" exists in the registry and it does not allow the user to change the <InstallDir> value. In fact, if the registry value can't be found, my update will halt. This allows registered users of generic apps to install updates without entering their serial number again while keeping non-registered users from getting a free copy. (The Condition options in Astrum are a very powerful tool.)

On the other hand, the 'install' routine checks for the A5 "RTExeLocation" and uses that as the default if it exists (i.e., the user is re-installing the app for some reason) but has a default <InstallDir> that it uses when the A5 runtime hasn't been installed yet - in which case the "RTExeLocation" won't exist. When running the full install, the user is allowed to change the <InstallDir> regardless of where the default install path comes from.

DEVELOPER HINT:

I'm sure this doesn't happen to anyone else (said with tongue firmly embedded in cheek) but sometimes A5 locks up and I have to kill it with the 3-finger salute. If the app still shows up in the Applications tab, no problem. But if an app has crashed or shut down incorrectly and no longer shows in the Applications tab then I have to check the Processes tab which only shows the program name - typically Alpha5.exe. The problem is that I often have multiple copies of A5 running - sometimes 3-4 different apps and always at least 2 because I keep the app for my Business running all day so customer info is immediately available. The trick in that case is figuring out which one to kill. To make this easier, I make a copy of the Alpha5.exe file and use a different one for certain apps. My business app always runs from Alpha5_aims.exe and many of my v7 apps run from Alpha5_v7.exe. My Trak_It.adb runs from the Alpha5_ti.exe since it has the most users and is therefore frequently open because of the additional phone calls. Now when another Alpha5.exe app crashes, I don't end up killing my business app by mistake.

You can also use this method for hiding the fact that your application is running from Alpha5. Obviously this is most useful for generic apps. The A5xxx.dll files will still exist but your exe file could be named, for example, Trak_It_SP.exe. And, yes, you can have multiple copies of the exe file all in the same development folder - as long as the names are different of course.

WARNING: If you do this, also make a copy of the Alpha5.errors and Alpha5.exe.manifest files. For example, my Alpha5_aims.exe has a matching Alpha5_aims.errors and Alpha5_aims.exe.manifest file.

[GordonMac]

Re: Installer question

Yep. And I've discovered that this can be a very bad idea. Far too often something will work on your machine but not on the user's machine because of something else that is already set up in your machine.

I went out and bought a used computer for $75 and use it as my "clean machine". I use it only to test install routines. Every time I finish a test I remove all files and folders and then run a System Restore to a previously saved "Clean Time".

I keep wondering if I couldn't just do a full registry dump and restore that to save time over running the system restore. Anybody know?

Hi Cal,

Thanks for that commentary. I do need to get another machine for testing. Don't know about the registry dump question. Thanks, Gordon

[GordonMac]

Re: Installer question

What I posted will really only save the "datapath" but the others could easily be added. The Company Name and Application Name are only used as keys - not 'values'. I don't believe a key is easy to retrieve.

True. But there's a big difference between updating the application and updating the runtime IF they are in different folders. Mine are always in different folders.

If I do a full "install", then I will install the runtime in the runtime folder and the application is installed in a subfolder of that. So, for a full REinstall, I need to get the A5 location from the registry. For a new install it just installs to whatever default location I've defined since it probably won't be able to find the location of an A5 program that doesn't exist yet. For an update, I only install the application files so then I need the "datapath" that my app saved in the registry. (On my own machine, the A5 program is on the D: drive and the development versions of the applications are on the E: drive but that's another story because I don't run the same install/update routines on those.)

My update routines are nearly the same as my install routines except they don't include the runtime because the runtime files seldom need to be updated for users and having them makes the update file MUCH larger. They also don't include the original data files but if I've added any new .dbf files since the original release, they are all in my updates.

All of my install/update routines have the data files (which I keep in a separate group) defined as "never overwrite" - that way I can leave them in the routines so anyone who hasn't updated yet, or who has installed an old backup that didn't have the files (rare but it did happen once), will get the new files and, at the same time, I don't have to worry about someone accidentally overwriting their existing data.

FWIW: Some of my update routines (remember - they install to the application folder which is NOT the same as the A5 folder for my apps) also install and register those .dll and .ocx files just in case. To do that in Astrum, you have to create a variable like <A5v9Exe> and tell Astrum to get the value of that variable from the registry. Then the files are installed to <A5v9Exe> instead of <InstallDir>.
Reg Location: HKCU\Software\Alpha Software\Alpha Five 9.0\ExeLocation\ExeLocation


As noted above, I'm not really saving the Company Name or Adb Name - they are only the names of the registry keys (folders) so I know where to find the "datapath" value. Some of my users have multiple apps so all their apps are under my Company Name key and each app has its own key under that. Within each app key is a "datapath" value.

Thanks Cal for the detailed explanation. I agree with Dave that as far as the runtime goes, the application and the runtime files can just as easily be in the same directory. However, for development purposes they really need to be in separate directories simply because different A5 applications need to be separated in order to run. Also, it is easlier to visually locate files when the runtime is not mixed in. However, for a runtime install this is a rather moot issue. More than that, a user may not recognize a separate runtime directory and if it is not a subdirectory they might think, "Why do I need this?", thinking it is something they need to clean up. I have done that... I should know better never to manually delete program directories... only uninstall. Duh! So I know it can happen.

Thanks,
Kind regards,
Gordon

[GordonMac]

Re: Installer question

A couple of years ago, I sent an app to another alpha user for testing something with a complete install including registry entries. It did mess their other alpha v5 apps up, because the settings they had were not the same as mine. Now, if I send something to another Alpha user, it comes with a warning or no reg entries.

In every case so far where I have sold a copy, the people did not have any alpha products, so it is kind of a moot point for me.

.

Great point Dave. Thanks for the advice.

Regards,
Gordon
SCS

[GordonMac]

Re: Installer question

Edit: I forgot to mention, my bootstrap app has code to register the dll's that always seem to have a problem. That way, if I developed it in folder "myapp" and the user decided he wanted it in "hisapp", the dll's are still registered to the user's location.

.

Again, thanks Dave. That is great feedback. I didn't think of the bootstrap application as needing the code to register the dll's. Thanks.

Gordon
SCS

[GordonMac]

Re: Installer question

First a correction of something I posted above. Since my apps are being installed with the runtime, I don't look for the ExeLocation as posted above. I look for the RTExeLocation:
HKey_Current_User\Software\Alpha Software\Alpha Five 9.0\RTExeLocation\RTExeLocation


First, just so nobody gets the wrong idea, I have no issue with installing both in one folder as Dave does. I don't do it because some of my customers have two apps and it would get really confusing with both in one folder. It would work; it's just more confusing. So, just to avoid having either two copies of A5 on one computer or two apps in one folder, I put the apps in a subfolder under the A5 runtime. This is strictly a matter of preference and/or the situation. Either method works. (This reminds me of something else - see below for another developer hint.)

In case anyone assumes that my method requires two install packages because they are in separate folders, it doesn't. Even though I have them in two folders, the fact that the app is in a subfolder means that it's still easy to install them both with one install package AND allow the user to change the location of the runtime folder. The runtime goes in the <InstallDir> folder - which I allow the user to change - and the application goes in the <InstallDir>\AppName folder.

For those not familiar with Astrum, the variables in Astrum are always enclosed in brackets so <InstallDir> is actually a variable name. In this particular case, <InstallDir> can be either 'hard coded', retrieved from the registry, retrieved from a text file (although that probably doesn't make much sense for this particular variable), or the user can (optionally) be allowed to select it.

The ability for Astrum to get the <InstallDir> from the registry is what makes my routine posted above so useful. No matter which workstation you're at, the update routine can still find the "real" data based on the "datapath" stored in the registry. This way there is no need to be on the server in order to install an update. So, my 'update' routine requires that the "datapath" exists in the registry and it does not allow the user to change the <InstallDir> value. In fact, if the registry value can't be found, my update will halt. This allows registered users of generic apps to install updates without entering their serial number again while keeping non-registered users from getting a free copy. (The Condition options in Astrum are a very powerful tool.)

On the other hand, the 'install' routine checks for the A5 "RTExeLocation" and uses that as the default if it exists (i.e., the user is re-installing the app for some reason) but has a default <InstallDir> that it uses when the A5 runtime hasn't been installed yet - in which case the "RTExeLocation" won't exist. When running the full install, the user is allowed to change the <InstallDir> regardless of where the default install path comes from.

DEVELOPER HINT:

I'm sure this doesn't happen to anyone else (said with tongue firmly embedded in cheek) but sometimes A5 locks up and I have to kill it with the 3-finger salute. If the app still shows up in the Applications tab, no problem. But if an app has crashed or shut down incorrectly and no longer shows in the Applications tab then I have to check the Processes tab which only shows the program name - typically Alpha5.exe. The problem is that I often have multiple copies of A5 running - sometimes 3-4 different apps and always at least 2 because I keep the app for my Business running all day so customer info is immediately available. The trick in that case is figuring out which one to kill. To make this easier, I make a copy of the Alpha5.exe file and use a different one for certain apps. My business app always runs from Alpha5_aims.exe and many of my v7 apps run from Alpha5_v7.exe. My Trak_It.adb runs from the Alpha5_ti.exe since it has the most users and is therefore frequently open because of the additional phone calls. Now when another Alpha5.exe app crashes, I don't end up killing my business app by mistake.

You can also use this method for hiding the fact that your application is running from Alpha5. Obviously this is most useful for generic apps. The A5xxx.dll files will still exist but your exe file could be named, for example, Trak_It_SP.exe. And, yes, you can have multiple copies of the exe file all in the same development folder - as long as the names are different of course.

WARNING: If you do this, also make a copy of the Alpha5.errors and Alpha5.exe.manifest files. For example, my Alpha5_aims.exe has a matching Alpha5_aims.errors and Alpha5_aims.exe.manifest file.

Hi Cal,

You know, I never thought of the user having an existing A5 runtime and application installed. Of course, in that case you would want the application and runtime files in different folders. However, you also brought up a great point about naming the main runtime Alpha5.exe file and associated Alpha5.errors and Alpha5.exe.manifest files by a different naming convention. Does this resolve the issue brought up by others? Can the different registration settings be kept separate within the windows registry so that the registry problems with multiple runtime installs mentioned by Dave and others... be eliminated?

Kind regards,
Gordon
SCS