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
