Recently I made an application that has lots of PDF files in it and I made a setup for it using Inno Setup Compiler. In the setup, I allowed people to change where they want to install the app. For opening my PDF files, I used: system.diagnostics.process.start("My pdf.pdf")
My problem is that in the code above, I put drive "C:" and when my user changed the install directory to drive "D:" the pdf's did not work and the error showed that "Cannot find the specific file". My question is that is there a way to just put the name of "computer" or "a drive" in the code above, not the specific name of the pdf, and let the computer find the file itself?
You seem to be asking for an opposite of what you actually want to achieve.
I assume you are installing files with known names. What you do not know is the directory of the files.
From your description I assume that your actual code is like:
System.Diagnostics.Process.Start("C:\My pdf.pdf")
But when the user chooses a different location (directory) for your application, the above code with a hard-coded absolute path fails.
If your application installs to the same directory as the PDFs, just use a relative path (in this case just a file name without any path). It makes an operating system look to the current working directory, which will typically be an application directory.
System.Diagnostics.Process.Start("My pdf.pdf")
Or to make it more reliable, make it explicitly look to the application directory. For that use Application.StartupPath:
System.Diagnostics.Process.Start(
System.IO.Path.Combine(System.Windows.Forms.Application.StartupPath, "My pdf.pdf"))
See also Get program path in VB.NET?
Related
Honestly, I don't fully understand my question, but hopefully I can still be fairly clear about it.
I just wrote a simple project in Objective-C/Xcode. It looks like Xcode generated an executable in a folder called "Debug" and when I double-click on it, it opens a terminal window and runs fine. However, while running, it reads from a text file in the same directory that it's in. So if I want move the executable to a different location, I also have to move the text file to the same location or it won't be able to find the text file.
My question is... when I download an application on my computer (like Google Chrome or Evernote), it comes as its own file and I can place it in any directory I like; there are no associated files I have to move whenever I move the "executable". Is there a way to generate a clean application like this using Xcode?
I have a very particular case and I don't know if this is possible to be done.
I'm using NWJS to run a web app as a desktop app. I need to zip/package the source files because my code should not be available to eavesdroppers. This package will be delivered on a flash drive. And this is were my trouble begins.
There are a lot of .pdf file that must be shipped together with the package. The user can browse which pdf he wants to open, and when he clicks it, the pdf is "downloaded" to his pc. The content of the pdf is NOT available on the application. I have a list with the name of each pdf file.
If I zip/package the .pdf together with the source files it becomes a huge .nw file and it takes forever for my application to load. I need to mantain the pdf on a separate folder and they need to be accessible through the source code. This is easy if i run the application directly without packaging it, as nw uses the relative url to it's root, but when I do package nw uses a temp folder for the source files and I can't use relative url to access the pdf folder.
The only approach i can think of is to write a js script to identify where the flash drive was mounted but i don't know if this is possible.
I have to support Windows and Mac for this case.
Searching on NWJS google group i found that the answer was quite simple. These two lines returns the path where the nw bin is running. From there is quite simple to get the pdf folder.
var path = require("path");
pathstr = path.dirname(process.execPath);
I'm creating a WIX installer for a C# application.
In the application I use System.Configuration.ConfigurationManager.AppSettings[Setting1] to get settings.
My question is, where must I place the program.exe.config file on the machine in order for it to work?
I can't place it with the program in ProgramFiles directory, since those files are read-only.
I tried:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
config.AppSettings.Settings[Config1].Value = "Value1";
config.Save();
Unfortunately I don't know where it's looking.
Thanks your replies, Trevy
It should be in the same folder of the program.exe. Use wix to copy both program.exe and program.exe.config to the required folder.
If you need to edit the configuration file during the installation you will need to do it using a custom action in wix. Make sure you pass the file path to the custom action and write the code to read the configurations in that file and edit.
The problem isn't that the files there are readonly - the problem is that you are trying to update files in the Program Files folder with your config.Save, and you can't do that if you are a limited user, and you are always limited (even if you are admin) unless you elevate. The short answer is that:
If your app routinely updates files in restricted areas then it probably needs elevation, so give it an elevation manifest.
If however you require you app to be used by limited users and allow them to update that config file then don't install to Program Files. Choose User Appdata folder, for example. Windows is probably using your config file during program startup, so you can't separate it from the exe.
When I was creating an installer for my app, I found I couldn’t save my settings.
The reason is because the Program Files repository, from a practical point of view, is read-only (Applications should never run with elevated permissions). When installing a program, the only time we modify the MyApp.exe.config file is at installation/upgrade/repair time.
The config file has many sections. One of them is userSettings. This is where we store any data we need to modify during the lifetime of the application. When run for the first time, Windows creates a hidden file in the user’s AppData folder. That is why we can save user settings, even though the config file is in the same directory as the MyApp.exe
So the answer is, if we run into permission errors when trying to save our settings it means we are writing our settings to the wrong section of the config file. We need to place it in the userSettings section and nowhere else.
For convenience, Visual Studios has a settings editor (the settings tab of the properties page). It allows you to create strongly typed user and application settings. The generated class lets you save user settings, but not application settings for the above reasons.
I am running Cincom VisualWorks version 7.9.1 in Windows 8. When I open the class browser and view a library class, it fails to display the source, instead displaying an error comment like this:
" ***This is decompiled code.***
This may reflect a problem with the configuration of your image and its sources and changes files.
Please refer to the documentation and the settings tool for help in setting up the proper source
code files."
I have confirmed that the home path is pointing to the correct directory. How can I fix this?
The answer to this question depends on what code you're looking at. In VisualWorks, source code can be stored in a number of different places. For classes that are present in a clean VisualWorks image with no other code loaded, the source is in a file called visual.sou found in the image directory of the installation directory. As you mentioned, you need to make sure the home path is pointing to the correct directory. It doesn't point at the image directory itself but the directory above - for example, it would be C:\Program Files (x86)\Cincom\vw7.9.1 not C:\Program Files (x86)\Cincom\vw7.9.1\image.
For parcels you loaded, the source code is in a .pst file associated with the parcel. For any code you load from Store or write yourself, the source is in a .cha file in the same directory as your .im file and with the same name. If your image is visual.im then your code is stored in visual.cha.
You need to be very careful about the versions of the files you use. The visual.im file is tightly coupled to the visual.sou file and contains offsets into the .sou file. If you're using a visual.im from another version of VisualWorks, those offsets into the .sou file may not be correct and may produce this problem.
I hope this helps.
I have a VB program that creates a temporay PDF file then opens Outlook and attaches the file. I create the file in the application path (the location that the program is running from - normally C:\Program Files\ProgamName). This works fine in XP as it appears there are no crazy permission issues. However in Windows 7, the file does not appear. There are no errors, the file does not exist in that location.
I've changed the path to the root of C:\, however this doesn't work either. I suspect it's something to do with W7 virtualisation, so the question is where can I create a file that I can then access again?
I was trying to avoid creating it on a share on a server, but it's looking like this is the only place to put it as there doesn't seem to be many places a user can write files to in Windows 7.
Surely there must be a location that users can access (without being administrators) to create files. Don't even get me started on the fun I have had with the registry in W7!!!
Thanks
Patrick
You need to create the file in the system's temp directory, which you can find by calling Path.GetTempPath().
In general, your program should only write to files in the user's Application Data (or temp) directories and only write registry keys in HKEY_CURRENT_USER. (This is true in any version of Windows)
If you follow these guidelines, you won't have any trouble in Windwos VIsta or 7.
You should never write information to places that are shared by multiple users.
Edit: While the following will work, SLaks points out it's bad practice, and the temp file won't get cleaned up.
Try %HOMEPATH% - this is the environment variable for a users documents folder, and should work no matter which version if windows you use.
In other words where you used to have:
"c:\programfiles\programname\tempFileName"
use:
"%HOMEPATH%\tempFileName"