How about creating a File management shared object that runs at startup and can save a DB of VBS and their associated files? Theapp could on startup look for VBS files that have gone missing and clean up the registered auxiliary files. Regeristerfile.create “path” registeredfile.Delete(
The DB should have entries like Application FileName FileType Permanent path Best wishes, Jonathan On Jul 28, 2014, at 8:22 PM, LBX <lab...@fltg.net> wrote: > Chip, > > The discussion was how to get rid of folders and files in the app that > would normally not be removed when you remove/unload the app. > > When the command to remove is given the log file tells the uninstall > program inside the WE environment to also remove any folders created. I think > that is a very simple understanding, don't you think? Or place the info > inside a shared object. > > I mentioned a shared object only to have some kind of global control, such > as the one that creates the xml and posts, stores the path to the folder > where all apps reside. See my example below which is from my Trek game > program. > > A simple fix that will exist inside the WE environment and the programmer > can assign to the object to notify the WE environment that it exists. So, a > little knowledge is needed by the programmer of the app. Or have an object > that does all the work like my simple MoveFiles subroutine does... > > A very simple fix and if the programmer does not want to remove the data > folder, then they never assign the path/name of the folder to the shared > object...very simple isn't it? Use the ClientInformation object to do all of > this. > > Trek Game Example: > ' The following variables set up specific app information, such as > ' the locations to the app INI and XML files. > > Dim myINIFile : myINIFile = ClientInformation.ScriptPath & "\Trek.ini" > Dim myXMLFile : myXMLFile = ClientInformation.ScriptPath & "\Trek.xml" > Dim myTrekData0 : myTrekData0 = ClientInformation.ScriptPath > Dim myTrekData : myTrekData = ClientInformation.ScriptPath & "\TrekData" > Dim clientPathToExe : clientPathToExe = ClientInformation.ScriptPath & "\" > Dim mySapi45ClassFile : mySapi45ClassFile = ClientInformation.ScriptPath & > "\TrekSapi45Class.vbs" > > Note all these files and folders can be assigned to the ClientInformation or > one single logfile which is read by the ClientInformation for use in removal > of the app. > > Bruce > > > Sent: Monday, July 28, 2014 5:59 PM > Subject: RE: Building Tidy Apps, with internal files > > > I don't understand how knowing the files involved would help you after the > user has uninstalled your app? > > Chip > > > -----Original Message----- > From: LBX [mailto:lab...@fltg.net] > Sent: Monday, July 28, 2014 7:48 AM > To: GW Scripting > Subject: Re: Building Tidy Apps, with internal files > > Hi Aaron, > > I was wondering on this thread if a log file shared object could be > added to the Tools app? > > What I am saying is, have a program writer include in a shared object > all external files and folders that the app uses besides the standard 3 > files, .vbs, .xml, .ini? > > Thus having the ability inside a logfile to track all files and folders > installed with the app. This is what the uninstall program utility uses > when ridding itself of any programs on the windows environment. Granted some > things are not erased thus the Revo program was written to take care of that > but that is for any registry additions that were done; which these apps do > not...and manufacturers add there own uninstall using that log file, thus > the WE environment would be doing the same. > > Bruce > > > Sent: Monday, July 28, 2014 1:23 AM > Subject: Re: Building Tidy Apps, with internal files > > > Hi! > > Yes Chip but my 2 games use the technique including keeping the .exe > file if any compiled program needed for the app. > > But, any future modification to the WE environment would be capture of > such a folder. Just a thought but could be an added feature after > installation of apps but does produce some extra look ahead stuff. But > having said that, that is what log files are used for in all installations. > A log file is also used for deletion of an app from the program list... > > Bruce > > Sent: Sunday, July 27, 2014 4:15 PM > Subject: RE: Building Tidy Apps, with internal files > > > Hi Rod, > > I understand what you're trying to do with tidying up the associated .ini > file; however, there is a downside to including it as part of the files in a > .wepm. If you do so, then every time you issue an update, the .ini file in > your .wepm file will overwrite the user's settings, causing him to lose all > of his hotkeys (for this app) and other customizations. > > Other than the naming scheme you suggested, I don't think there's much else > we can do to keep things tidy until GW adds an event for uninstallation of > an app. > If we have our app move files into sub-dirs after installation, then these > files will never get cleaned-up when the app is uninstalled. Looks nicer > while our app is there, but leaves behind quite a bit more than a single > .ini file. > > Chip > > > > > -----Original Message----- > From: Rod hutton [mailto:rhst...@sympatico.ca] > Sent: Saturday, July 26, 2014 1:12 PM > To: gw-scripting@gwmicro.com > Subject: RE: Building Tidy Apps, with internal files > > Hi David, > > I so very much enjoyed your discussion of this > important matter, as, indeed, you probably already > know, I enjoy all your most sincere and thoughtful > posts. > > I wanted to mention a few things about app > packaging from my own experience. You probably > already know most of these things, but I thought I > would mention them for clarity and possibly for > the benefit of those who have less experience > than some of us. Also, perhaps I can learn > something as well. > > One thing I have noticed is that if you don't > include an INI in your package, leaving the > creation of one up to your app, then, when you > uninstall it, the INI will be left behind; > conversely, if you include one in your package, > then it will be removed when your app is > uninstalled. I mention this just for clarity, > since we're looking for a complete picture of app > tidiness. > > Also, I learned through experience that the best > way to gather files is to prefix each and every > filename a given app requires with the name of the > app, followed by an underscore, followed by the > unique filename. This way, if you sort the files > in the WE prifile folder by name, and use > first-letter navigation to go to the app's files, > they are all together in one place. This also has > the advantage of avoiding losing files due to the > uninstallation of other apps, since it is unlikely > that anyone prefixes their app-related files with > a name corresponding to the name of one of my > apps. I do, however, like your idea of grouping > app-related files into folders; I had even wished > to do this in my early days of app writing. > However, one thing I learned for certain is that > one had to place the VBS file of the app in the > profile folder; otherwise, WE would load multiple > instances of my app on subsequent startups of > Window-Eyes. So, it became clear to me that I had > to develop my own system of gathering files > related to my apps, and so the present system > seems to work well for me. > > I agree that we need a more comprehensive system > for app management, and perhaps this is coming. > For now, we can continue to learn from each other. > Thanks for your efforts in this regard, and thanks > for listening. > > All the best, > > Rod > > -----Original Message----- > From: David [mailto:trailerda...@hotmail.com] > Sent: Saturday, July 26, 2014 6:24 AM > To: gw-scripting@gwmicro.com > Subject: Building Tidy Apps, with internal files > > This message may well apply to any app developer, > who realize that his > app will access one or more "internal" files. > > When creating a well-designed app, you are likely > basing your code on > the Framework GW provides you, through the > Framework app. Or, you may > alternatively produce similar coding. Whichever > way, most cases your app > holds the main file with the code, along with an > ini and an XML file. > Let's face it, these are the three "elementary" > files of a fully > functional app. And due to the way GW has decided > to build their > scripting environment, these three files basically > need to be in the > User Profile folder, for any user who will need > access to the app's > functionality. > > Once in a while, your app will produce some > temporary files. These could > be used for temporary storage of any information, > or simply as clear-cut > dumps for information that has to be handled for a > given moment in your > code. Whatever the purpose, they are only meant > for rather short-lived > usage, and may not need to be stored for eternity. > Good coding, of > course, would demand that you clear out any such > files, once the code is > done with the contents. But there well enough > could be times, when you > determine it will be best to keep this kind of > files for a little while. > > Next, we have the Log files. These also are meant > to only store > information relevant to your app, and extremely > rarely will be of any > benefit to any of the rest of apps installed on > the end-user's computer. > > Finally, we have what we best may name the > "Assisting" files. This could > be any kind of extra material, that your app > relies on for its > functionality and features. It may eventually be > some kind of .exe > files, or it could be sound clips. Sometimes it > could be different kinds > of text files. Let's also here include any kind of > documentation files - > be it .chm, .html, .doc or plain .txt files. Again > most cases, only your > app, will be the user of these files. Other apps > may not have access to > the information here stored, or even have any > interest of it. For > instance, the sound clips of your app are meant to > be clearly distinct > from the sound clips used by any other apps. The > documentation of your > app, does have nothing whatsoever to do with the > apps constructed by me > or anyone else. Hence, let's face this fact as > well, these ar internal > files, that only has a relevance and meaning to > your app. > > > Looking at my User Profile folder, under > Window-Eyes, I find a true mess > of files. There would be numerous set files and > .we files, all connected > to the immediate behavior of my screen reader in > different work > environments. Great, we won't bother about these, > as they are there for > their clear purpose. > > Next, i find a good chunk of .vbs files - or > .vbs.wepm.crypt files (for > encrypted versions - all being the main code files > of apps currently > installed on the machine, for the active user. > Along with these, I find > the expected ini and XML files. GW did - at an > earlier state - indicate > that they had some sort of idea on the slate, for > a more tidy way of > installing apps. Leave that on the slate for the > moment, as there is > little you and I as app developers can do about > it, until GW releases an > updated environment for us to organize our apps in > more tidy manners. > Consequently, these files will have to populate my > User Profile folder, > and I can deal with that well enough. Typically, > they will hold names > that clearly link them with the app they are > representing, and if each > app only holds three files or so, it still won't > disturb the > transparency of my folder. > > But then, what do I find more in the User Profile > folder? No less than a > ton of internal files, for whatever app it may > happen to be. An app like > the ProgressIndicator, which comes standard as > part of the modern > installation of Window-Eyes, has something like a > hundred sound clips. > Clips that are meant to only be used inside this > app, and which > extremely seldom will have any meaning for any > other app on the machine. > Other apps, are loading down the folder with their > sound clips, log > files, extra third-party software snip-its, > documentation files - and > who knows what else. Sorry to say, but I do see > little benefit in them > sitting here, and they sure are in my way when > attempting to refind a > given file in my folder. > > Try for instance, to look up a file that starts > with cs, if you happen > to have the Hourly Chime app installed. You first > will press C, and then > start arrowing down the list. Soon enough, you > will arrive at CR, and > here you will have to scroll pass numerous files > named something with > "Crystal" followed by a number. These are all > files meant only for the > Hourly Chime app. Yet, there is no indication of > that relationship. For > an end-user, it seems to be files that has no real > value. And what if > she now decided to delete these files? Next time > the Hourly chime goes, > the app will fail, and the user won't have a clue > why. Then they > complain about the app's malfunctioning, you end > up doing a ton of > error-tracing; all only to realize the cause of > the trouble experienced. > Or, try to find a file starting with the letter P, > and see how many > sound clips, you will have to scroll by before you > hit your final > choice. We could go on with several examples, > samplifying the anoyance > of all kind of internal stuff, for different apps. > It is truly messy, > gives a lot of extra work in finding needed files, > and may only serve to > confuse less educated users. > > > The Solution > Although GW has not yet released an environment > that lets us organize > all our app content into corresponding subfolders, > there still exists no > limitation as to where your app stores its > internal stuff. It is totally > and fully possible for your app, once running, to > pull its information > from internal files that are stored in a distinct > and corresponding > subfolder. Or, for that matter, a folder anywhere > else on the computer. > Basically, even your Ini and XML files, could > easily be transfered to > reside inside an app-related subfolder. You just > need to modify a > handful lines, in the code produced by the > Framework script. Same goes, > whenever your personal code attempts to derive > information from any > file, or base its functionality on such internal > files. They can be > accessed, no matter where they are stored. And > what's the real good > news, it does take very little extra effort for > you as the developer, to > have this happen. Let me show you one simple > example, which you can > modify right into any of your app codes, this very > afternoon, smile. > > Imagine, you are developing an app, which we call > MyNewApp. It will base > some of its activity, on two files - a sound clip > named MySound.wav, and > a documentation file named MyDoc.txt. Typically, > your current code, > would look something like this: > Set FSO= CreateObject( > "Scripting.FileSystemObject") > PlaySound( "MySound.wav") > MsgBox FSO.OpenTextFile( "MyDoc.Txt", 1 > ).ReadAll() > Note: I have cooked the sample code here, down to > a minimum - only > dealing with the actual lines of interest for the > example. Your code may > likely hold several more lines, to ensure > error-free execution. > > Now, we want to do things in a more tidy way, > moving all our internal > stuff into a subfolder, related distinctly to our > app. We could have a > subfolder named the same as the app - MyNewApp, or > MyNewAppFolder. For > the clarity of the sample code, I suppose you have > named it > MyNewAppFolder. The two last lines of the above > sample code, now will > look like this: > PlaySound( FSO.BuildPath( > ClientInformation.ScriptPath, > "MyNewAppFolder\MySound.wav")) > DocFileName = FSO.BuildPath( > ClientInformation.ScriptPath, > "MyNewAppFolder\MyDoc.txt") > MsgBox FSO.OpenTextFile( DocFileName, 1 > ).ReadAll() > Not too different from the above, is it? > > We use the ClientInformation.ScriptPath function, > to retrieve the full > path string of the current User profile folder. > You likely already do > so, in all your file requests, to ensure you will > find stuff stored in > that folder and nowhere else. Then, we make use of > the > FileSystemObject's method of BuildPath. This only > to make sure that a > proper complete path string is produced, when we > combine the app-related > subfoldername, with the current ScriptPath string. > For instance, it will > automatically insert the needed backslash between > the two strings. Then, > we quickly request the file from the produced > pathstring, which means, > we pull the file from the app-related subfolder. > You now can store all > your internal stuff directly inside this > subfolder, clearing up the > transparency and user-friendliness of the user > Profile folder itself. > '''Updating Your Code' > Then how about all your existing apps? Will you > have to do a ton of > modification to have them go more tidy? As shown > above, only minor > modifications may be needed, in your internal file > requests from inside > the code. And, you can easily enough have your app > sort its stuff into > the app-related subfolder as well, through the > installation process. For > new packages, i do suggest that you could have all > the internal stuff > packed up in an executable file (.exe), and simply > run this as part of > the installation process. This is what I do in the > Extended Dictionary > package. It does take a bit of coding, and you > will need a means of > packing the needed files into an executable, but > it all can be done. > > Another - and perhaps just as effecient - way of > handling things, would > be to let all the files be unpacked into the User > Profile folder, and > then let your app have a sub-routine that moves > all the stuff into the > app-related subfolder. This routine could be > constructed the way, that > it will create the subfolder should it not already > exist, and then > simply just move any of the internal files over > there, one by one. If > now, you let your app always run this "moving" > routine at the very > startup, you need not worry if people just updated > to your new version. > Any of the files that exists from the previous > version of your app, > would then be moved into the app-related > subfolder, and hereafter be > accessed from there. > > > One Single Drawback > It would be greatly encouraged to do this kind of > tidy app organizing. > Look at any of the professional software you buy > and install, and most > of them will have their stuff sorted into a > software-related subfolder - > somewhere on your system. Not really aware of any > other software, that > so consequently installs all its mess and > internals, in one big hive. > Yet, there does exist one tiny drawback to this > approach of app > developing, long as GW has not updated their > scripting environment. To > what extend they can do so shortly, or if this > will have to be dealt > with at a later state, I do not know. > > The drawback is, that if the user decides to > uninstall your app, the > current environment will only uninstall what is > stored directly in the > User Profile folder, and was originally included > in the .WEPM package of > your software. That means, if you put things into > the app-related > subfolder, it will not be automatically removed as > part of the > uninstalling process. The user will have to remove > the stuff manually. > Not a big deal, your documentation could give > instructions. And since it > all is stored in one subfolder, all the user has > to do, is to go to his > User Profile folder, locate the app-related > subfolder, and hit Delete. > On the other hand, since the stuff does not get > removed through > uninstallation, you could use the approach to make > sure the user does > not loose settings, or other important data, if he > temporarily removes > the app from the computer. It even makes it a > breze for the user, to > transfer all the internal things, to another > computer, and your app > could even offer this kind of features. Compared > with the rather small > extra step needed through uninstallation, the > organizing of app-related > subfolders, really holds that many benefits for > both you and the > end-user, that I do stress its importance once > again. > > > Friendly reminding you, > -- > David > > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com >
