Randem Systems Support Board

Why do you think that application data path is not good?
 
Because it's not the folder where the app and data is, not that I expected it would be.
 
I agree about Win95.  I was wondering why you included it in the script you did for me.  Based on a survey of our users I'm thinking about eliminating Win98 also.
 
Thanks for the code for determining the Windows version.  It may be useful in the future - not now because I'm going to take your advice and get the data out of the app folder via {userappdata}.
 
Final question (at least for now): What are the effects of checking/not checking the Allow NoIcons item in Parameters?

I have tested {userappdata} under Win98 and the data goes to WindowsApplication Data. That is the default for Win98 and I don't know where it would go under Win95. I would choose not to support this OS for various reasons.

Getting the data out of the app folder would be good for all OS's. Why would you want to deal with a different set of rules for each OS.
 
Why do you think that application data path is not good?
 
If you want to set the APPDATA environment you can shell to DOS and use the Set APPDATA = yourpathname command. Yes, there are ways to determine the OS in VB code using API's.
 
Ex.
 
Private Declare Function GetVersion Lib kernel32 () As Long
Public Function GetWinVersion() As String
    Dim Ver As Long, WinVer As Long
    Ver = GetVersion()
    WinVer = Ver And &HFFFF&
    'retrieve the windows version
    GetWinVersion = Format((WinVer Mod 256)   ((WinVer \ 256) / 100), Fixed)
End Function
 
Private Sub Form_Load()
    'KPD-Team 1999
    'URL: http://www.allapi.net/
    'E-Mail: KPDTeam@Allapi.net
    MsgBox Windows version:    GetWinVersion
End Sub

In running the app on my XP development machine, Environ(APPDATA) returns:
 
C:Documents and SettingsTomApplication Data
 
Not good.  Forgive my inexperience but:
   -- Is there a way to determine the OS in VB code?
   -- If so, can I Set APPDATA in VB code?
 
Or, maybe I should just bite the bullet and get the data out of the {app} folder for all OS's not just Vista.

If you use Run As Administrator on the clients machine that does not give access to the protected areas of the server unless you the same user and password is and admin on the server also and they have to be logged on, Not good. Too much power for the user to do damage to the server...
 
As far as a Win95 install, I don't know what it would return but my guess would be either it would return nothing or the {app} path. That would need to be tested though.

In my 95-XP setup I have the data files in the same folder as the app - that is, the Destination Directory for the data files is {app}.  What is Environ(APPDATA) going to produce in that case?  If not the app folder then I'm going to have to redo the 95-XP setup to put the data in a separate folder.

Vista Standalone Computer Install: I understand what you are saying regards GHMDATA as a subfolder under yourappname (which is GHM).  But, IF I wanted GHMDATA to be a standalone folder, are you saying that a template change to DestDir: {userappdata}GHMDATA will do that?
 
Vista Network Install: I really want to stay away from our neophyte users having to do separate installations for the server and clients.  I know you discourage Run as Administrator, but would that not be a simpler approach, and would it not apply only to this one app?  Does checking the Vista Admin Request box provide Administrator privileges for the app on a client?

Sure, If you had the folder under your development folder it would amount to the same and be the preference. Ex. Your development folder is GHM ande under that folder is a sub folder GHMDATA. IF you add this folder (GHMDATA) in add folders on the target system it would either go to {app}GHMDATA or {userappdata}yourcompanynameyourappnameGHMDATA on the target system.
 
It should not be confusing to your users. All you need to do is to create a batch file that will copy the data to a location they can find when you want them to send you data. Perhaps the temp folder inside a folder named GHMDATA.
 
In reference to a server install you do not use {userappdata} because the user would not be able to access it for they would need administrator privilegews on the server to see it. That is where you would use something like C:UsersPublicyourappnameGHMDATA to have your data. You would need to seperate installations, One for the server install and one for the client install.

In addition to my question above about network workstation installs, another question.
 
I have this simple concept that I want the data in a folder named GHMDATA.  I placed the data files to be installed in that folder on the development computer; put the files in Add Files with the folder as the source; and added the folder to the Search Files list.  However, apparently in InnoScript the PDW's Package folder takes precedence and the Destination Folder for the files becomes:
 
{userappdata}sportsware ltd.ghmpackage (6)ghmxpsupport
 
There are problem resolution situations in use of the app where we ask the user to send us one or more data files.  The above path may be a source of user confusion.
 
If I remove the data files from Add Files and place the GHMDATA folder in Add Folders I get the following Destination Folder for all the files sourced from C:GHMDATA*.*:
 
{userappdata}sportsware ltd.GHMGHMDATA
 
That's simpler, but I've modified it via template to {userappdata}GHMDATA - is that okay?

Got it (finally), at least with respect to a standalone computer.  For installs on multiple network workstations I have the user made a drive (e.g. Drive Z) to a UNC Path (e.g. \hostnamesharename) and change the installation path to that UNC Path, where sharename is a shared folder on the host.  That works fine when both the app and the data are in the shared folder.  What are the implications now that the data files will be in a different folder (the APPDATA folder) on the host?

Yes, if you check the files in Add Files they will go to {userappdata} which will become the APPDATA path on the target machine.
 
APPDATA is a default windows variable to show you where your data is supposed to go. If you open a DOS  command prompt and type in Set APPDATA, windows sets this path.

You say: AppDataPath = Environ(APPDATA)  
 
What I'm not understanding (dummy me) is how Environ(APPDATA) knows where the data is.  I assume in InnoScript that I check the data files in Add Files which gets them to {userappdata}.  Is that what establishes their location for the Environ statement?

When you reference the data in your app you do use fully qualified paths don't you... IE. App.Path & yourFileName and not just yourFileName, correct? If so you would just do the following:
 
AppDataPath = Environ(APPDATA)
 
Then replace all occurences of App.Path with AppDataPath. Simple... If you just used the filename you would have to prepend all the filenames with AppDataPath & ",

Note: If you are going to copy the data and change your app to reference the Limited User installations locations you don't want to use the Vista Template You actually want your program installed in the Program Files Folder.

Great. One thing your current users would have to do nothing when they upgrade if your upgrade program copies the data automatically for them. Since you know where it is to go and where the old data is also you don't need to worry them about it. On startup of your app, check the new data folder location for the existence of the data files, if they do not exist then you copy the users data to the new location and they are none the wiser and you get them in compliance with the Limited User model.