For years I've put my application data files in c:\MyCompany\MyDataFileFolder\App where 'App' is my application name. I made this choice in the early days of Wild-West-Windows when Microsoft seemed to keep changing its own mind (My Documents, Documents, Program Data etc). As I've learnt more about how to do things correctly, and as Windows has now 'settled down' and is more picky about permissions I'd like to move my files. Users have got used to where they are though, and what I'd really like to do is to implement something like Windows does with 'special folders' where there are several synonymous names, thus in my legacy folder I'd like to put something in (or change a folder to) an alias for the real location which will now be something descended from Program Data. This way, the files are in a good place with the correct permissions and if we run a utility expecting or modifying files in the 'old' place this gets changed transparently to the 'new' place (thus a simple shortcut wont work).
Is this possible? Is there are recognised technique for this? I'm using Delphi XE2.
What you are looking for is either a Symbolic Link or a Reparse Point.
Related
I have an electron app, and when I make it, it packages and compiles everything.
Sounds like it works perfectly right?
Well, problem is I want one of the folders to not be compiled, but still be accessible by my static files, so the users can add or remove content from the folders.
I've tried making it in a seperate folder, but then it can't find the files even when it's placed in the correct relative path.
Overall, I want my app to exist next to a folder and my <script src="./folder/script.js"></script> to actually be able to access it.
I'm new to basically anything node or electron so i'm probably making some dumb mistake.
Thanks in advance.
Having your user touching files close to your Electron application may be fraught with danger. If they accidently overwrite an important file or accidently delete an important file then your application may stop working and require the user to perform a re-install.
Instead, have any default files the user may need to "touch" packaged up with your application and then upon your applications first run, copy these files (and any necessary folder structure) over to the users home, desktop, documents, downloads or even userData directory.
That way, your application will always know where to find them and the directory is a directory your user will already be comfortable adding files to and removing files from.
You can always let the use choose where these files are stored as a settings option which persists in an application setting file, using something similar to path.join(app.getPath('userData'), 'settings.json');
See Electron's app.getPath(name) for more information.
Normally, when you read about localization resources (RESW) for a universal application you are asked to create a single resource file for each language with Resource.resw name or in a most advanced scenario they advice to create two or three like Errors.resw, Messages.resw and that's about it. We have completely different approach (let's don't argue upon this, for us it proved to be good). We have a separate RESW file matching a CS file where we have resources which needs to be localized. We mimic the same folder structure in the Resource(language)\ folders as we have in the source code. The whole pattern came from Windows Phone Silverlight application and worked perfect with RESX. I have concerns regarding this in universal app. The problem is that even though a RESW file is located deep in the directory structure like
Res\it\Controls\Browser\MusicDetails.resw
it is referred as if it is located in the language root at Res\it. For example to get this resource in the code the code would look like this
resourceLoader = ResourceLoader.GetForCurrentView(currentAssemblyName + "/MusicDetails");
resourceLoader.GetString("Title");
Getting back to windows phone silverlight app the path in a similar case looks like "\Controls\Browser\MusicDetails.resw" and it is definitely not an issue for the RESX resources.
Is there something we are missing or it is a hard RESW limitation and all RESW files no matter where they are located in the directory structure are treated as if they are at the root of the language directory? I foresee a problem if in the future we have exactly the same RESW name in different directory branches. How to work around this?
I think is not possible to do that, I tried to do something like you before with Windows 8.1 and it was not possible now with UWP is the same we need follow the guidelines here
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh965328.aspx
I did this steps and it works like a charm.
UWP apps have restrictions they are not like traditional apps (Win32 apps)
I would like to store some XML program preferences as a resource in a Delphi application. The resource would be modified based on user changes. I have no problem creating the XML and loading it as a resource, and can modify the xmlDocument that I load it into, but I don't know how to write the document back. Is this even possible? I would prefer not to end up with 2 files in the end (.exe and .xml).
The answer is both yes and no.
Yes, it is possible to update resources in a binary using Windows API routines. This link to BeginUpdateResource() should get you on the right track on that score.
However, you will note the following condition on the use of BeginUpdateResource():
"The binary file in which to update resources. An application must be
able to obtain write-access to this file; the file referenced by
pFileName cannot be currently executing."
In other words, it is not possible for an application to simply update it's own resources while running.
There are a number of strategies you could employ to achieve what you want - or something close enough to it as to be satisfactory. Which is most appropriate will depend on your precise needs.
Of the multitude of solutions, two might be:
1) Maintain all such resources in a DLL (resource only DLL - containing no actual code as such) which you open only when specifically loading resources (or updating them). Thus at the time you wish to write a resource back to the DLL you should be able to get the required write-lock.
or
2) When you need to update a resource rename the current running EXE to something like "myapp.OLD", copy it so that you have a new file with the current name "myapp.exe". You can then update "myapp.exe" because it is actually "myapp.old" that is executing.
This second approach is quite messy and has a "nasty smell" but is a technique that is (or used to be) quite commonly used by auto-updaters, for example. Obviously will involve a restart of your app at some point if the current running code is to make use of the updated resources in the modified EXE, so it may not be appropriate to your needs.
Something else to consider is that anti-virus software may flag the activity as suspicious.
Thinking about Deltics' answer I thought you could also create a console application that writes your resource back to the main exe. So your main exe saves it's changes to a file and also extracts the console app. When the main application terminates it calls the console app. The console app waits for a short period of time and then binds the resource file to the main executable, deletes the resource file and itself. The console app could do a check to make sure that the resource file was written successfully and, if not, leave the resource file open. The main executable could see the resource file upon start up and use it instead of the embedded file - as a safeguard.
All of this assumes a single user application.
I have written several applications in Delphi which use Word automation. The programs all use templates which are stored in a directory. In pre-2010 versions of Word, one would define the location of the templates in tools|options|file locations; the programs would pass the name of the template and Word would know where to find it.
My client has now moved to Office 2010, and as a result, Word cannot find the template when started by my programs. I haven't been able to find a similar dialog box in Word in which I can define the default directory for templates. How does one define such a directory?
Click File | Options | Advanced | File Locations and you get the same dialog as in older verions
Instead of forcing your user to configure Word to define the location of templates, you might prefer to invoke word using /t switch.
/ttemplatename starts Word with a new document based on a template other than the Normal template.
>"%programfiles%\Microsoft Office\Office14\winword.exe" /t"c:\MYTEMPLATES\mytemplate.dotx"
Can't you just specify the full path when creating a new document? Why rely on a settings that possibly can even be changed by the user? Put your templates in your own folder and specify the full path.
Word's paths configuration are stored
You can get the USER template folder via
Word.Application.Options.DefaultFilePath(WdDefaultFilePath.wdUserTemplatesPath)
(there are others options for that property too).
As far as I can tell, the template loading rules haven't changed from 2007 to 2010.
Generally speaking, if your add in needs to load a template, you should specify the FULL path and file name to the template, but you can get the typical user path via the above.
On the other hand, if you install the template into WORD\STARTUP, word will automatically load it. that may not be what you need/want, though.
Finally, if your template doesn't/shouldn't change, it might be better to leave it in your PROGRAM FILES\appname folder and load it from there.
Generally speaking, +requiring+ users to change the FILE LOCATIONS in word (or changing it programmatically) is a bad idea, just because so many people wouldn't have a clue, and those that do definitely DO NOT want addins changing those settings automatically!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Something I've wondered about for a while now and would like to get a general opinion on:
Advanced apologies if this has been asked previously, I did a search and couldn't find anything similar. This question is related to questions like, "Correct location to save a temporary file in Windows?" , but not quite the same.
I've noticed over the years spent with Windows, from XP to Vista and now to 7, that the 'My Documents' directory has slowly turned from being a place where you're encouraged to place personal 'stuff' into a dumping ground for any junk any random application wants to store.
For example, if I look now at the 'My Documents' directory on my work xp machine, there are folders for Adobe, FX Composer, Maya, Processing, Visual Studio 2005/2008, Visual Studio Samples, Window Clippings, Evernote.... the list goes on and on.
In fact, the last thing that I'd ever use that folder for now is storing my 'stuff' - the very thing it was intended to do. I personally find storing my actual documents in there, along with these random application settings too disorganized and painful to sort through. Plus there are added headaches with backup software etc... The signal to noise ratio just becomes appalling.
Lamenting aside, I now find myself in the position of writing some code where I want to store some settings related to my application. These settings ideally should be 'global' (our software gets regular updates), so storing them in some Program Files directory that's likely to be ephemeral won't work. While settings themselves could be stored in the registry, what about backup files, compressed archives, samples, etc etc...
So really what I'm asking is, what's the right solution for this situation? Do I follow the crowd and use 'My Documents' as a dumping ground? Is that folder a write-off anyway, or am I adding to the problem?
Do you use 'My Documents' as a storage area for your applications? Do you share my frustration with all the junk that turns up in there?
The users of my software are semi-tech-savy, so would probably understand it's just a directory like any other (and so could handle it being elsewhere) - but I guess Aunt Edna isn't going to understand that, so does the answer depend on context?
Thanks in advance!
Edit:
Thanks for the suggestion of %APPDATA% - I guess this is fine for application settings and files that shouldn't be exposed to the user, but what about files that might be useful for the user to move/manage themselves? Is My Documents the only solution or should I still stick to %APPDATA% ?
If these are application-private files (i.e. not user-visible documents) then isn't this what the %APPDATA% folder is for?
Just make this configurable at install time, and later by the user. Ideally give them just two choices, one being My Documents and one being APPDATA.
Make APPDATA the default but do allow this to be easily changed at install time for enterprise admins who want everything in the My Documents folder which is automatically archived.
Not a good idea as a 'dumping ground', but it simplifies backup, for a start.
In my workplace, users' My Documents folders are all on a network drive for ease of capture by an automatic backup system.
Just because applications are dumping stuff into "My Documents" doesn't mean they should. At the very least, if you need to dump things there, then make the folders hidden. Really, you should use %APPDATA%.
I'd say that Application Data is the place to keep settings etc., whilst My Documents (possibly in an application-specific sub-folder) would be the default place to keep output data files produced by your application.
Having the latter configurable via your installer / application settings dialog would be the nicest all-round solution.
How about following the unix/linux tradition of storing it under ~/.app_name? Just make sure it's hidden, and ~ could be the "My Documents" folder
In any of your library windows ( documents music video etc... )
just click the locations menu ( on the left side of your document pane's menu opposite the right side of the pane which contains the other menu: the folder drop down menu, for folder types )
it will be called locations or if you already have more than 1 location the menu will be called: Includes: n locations.
Just click that location menu and you can add as many document directories you want.
You can change the order so your specified directory is the primary viewed documents folder. ( And you can choose the default save folder to be the original folder. applications then dumped to the original default location, leaving your primary location pristine )
However in some navigation windows all the locations are viewed together as one huge documents folder.
( although messy you do have the advantage of navigating all those locations at one... so I suppose those search window prompts make sense? )
You can set a system env so that Maya will use your clean primary custom documents location instead of the default save location.
in the system properties control panel's advanced tab:
create/or edit a system variable for...
MAYA_APP_DIR
E:\myCustomDocs\Maya
( I use a different fast hard drive to save on my SSD system space. )
For added flexibility look up setup of hard link soft links and symbolic links!
where directory pointing as simple as:
mklink /J [old location] new location
Gives you alot more options and power!
Hope that helps?