I am trying to build an install CD with a custom MFC application set to autorun when the CD is inserted.
The instructions are included as a simple html page with images and links to PDF documents, all of which are located on the CD.
In the past I'd used the following to open the html page with the default browser:
ShellExecute(NULL, "open", <full path to .htm file including CD drive letter>, NULL, NULL, SHOWNORMAL);
But when testing with IE8 under vista I've encountered the following:
Explorer launches
The tab says 'Connecting'
Explorer dissappears
This has to do with protected mode, since if you turn off protected mode for the internet zone, the problem goes away.
The strange thing is that the problem only shows up once everthing is burned onto a CD. If I just run the autorun executable manually from my hard drive, the html page comes up just fine.
So I'm asking if there is anything specific I can do to fix this?
Or if there is another mechanism for opening URLs with the user's default browser that might not have this problem?
Since you can be reasonably sure that IE is installed you might want to execute
iexplore.exe [URL]
in your shellex call.
In case IE is not installed, check the return value to see if it isn't not found. If so do your original shellex call directly on the .htm file.
Alternatively, You can copy the .htm to a %TEMP%, and run the shellex call from there. That way it gets around the protected aceess from a "risky" location.
Can you capture and display the return code from the ShellExecute? That might give us a clue as to what is happening.
result = ShellExecute(...
Possible return codes are listed here:
http://support.microsoft.com/kb/238245
It says in your question that you are hard-coding the CD-ROM drive letter. Does the machine you are testing on have a different drive letter than the one you created the CD on?
Related
I'm trying to install the CS50 Appliance in VMWare Player, and it gives me an error saying 'Error converting to virtual machine - Unknown Error'.
It advices me to contact VMWare technical support and provide the log file in 'users/AppData', but there is no folder called App Data. Any advice?
well the folder called AppData is located in your Username directory, it's there, just hidden (because normal users shouldn't mess with anything inside it). You either copy, edit and paste this in a file explorer Window:
C:\Documents and Settings\YourUserName\AppData\
Assuming you installed Windows in C, and running Window 7 up.
Where YourUserName is the name you initially gave your account.
The other way you can do it is: go to start > run > type in "%appdata%" (without quotes) and hit OK. This is a better one.
Here's is also a step-by-step tutorial on it doing it another way
As for installing CS50, I've never done it before, but did you follow instructions here?
Also, this questions doesn't really belong in SO, you might want to try Superuser instead.
PS: Welcome to SO! :)
note: I already looked at the following question but it provided no insight: PDF file does not get open from ShellExecute function in Visual Studio, C++
I have the same problem as the poster in the above question.
Trying to open a PDF file from an MFC Application using ShellExecute. Adobe XI on Win 8 64 bit system.
hReturn = ::ShellExecuteA(NULL,"open",sPath,NULL,NULL,SW_SHOWMAXIMIZED);
sPath is a CString although I've tried alternatives with the same result. I've also tried SW_SHOW, SW_SHOWNORMAL. ShellExecute returns 42 when I cast the HINSTANCE to an int. I understand that means it opens successfully.
In fact, if I watch the task manager when executing the command, Adobe Reader opens in response in Task Manger but the Adobe window never opens.
When I exit my application, Adobe is still open.
If I try to open the target PDF file, the O/S says it can't be opened because it is already open in another application. When I "End Task" on the Adobe Reader in task manager, it frees up the file.
If I then click on the file, it opens fine in Adobe Reader.
So, I'm inferring from this that the ShellExecute is launching Adobe, that it is getting the right file, and that the file is, indeed, readable.
I've also confirmed that ShellExecute is working by directly referencing a txt file. It opens fine in Notepad.
hReturn = ::ShellExecuteA(NULL,"open","d:\\develop\\readme.txt", NULL, NULL, SW_SHOWMAXIMIZED);
Any ideas?
Thanks
try disable "Protected mode"
Adobe Reader - Protected Mode
This seems to be a known problem with opening a PDF file on Win8 via ShellExecuteEx. I had the same issue with an installer that would try to open a PDF at the end of the install process. On Win7 it worked fine. On Win8, it displayed the symptoms you describe. I was able to track it down to a problem with elevated privileges on our install program. I'm not sure why that would adversely affect things, but, it did. As an alternative, we looked at opening the file as an HTML document instead. We are still looking for a better solution.
I am trying to open a local html document using Shell Execute(). But, what i need is, Suppose if that particular document is already opened and if ShellExecute is triggered again, then that particular file should not be opened again instead bring the already opened file into foreground. Can you please suggest how can i do this?
void main()
{
ShellExecute(NULL, "open", "C:\\prograomgiles\\help.html",
NULL, NULL, SW_SHOWNORMAL);
}
It's nearly impossible, because it depends on which program processes the html files and how does it work. Suppose, that my OS opens html files by printing them directly on a printer. How would you bring opened file into foreground?
If you want to display HTML content in the way specified by you, write your own browser (It's quite easy, you can - for example - embed IE in C#.NET application) and run it instead of default system browser. You would have then full control on how your files are displayed.
Many web browsers respond to DDE messages, particularly the WWW_OpenURL message. Not sure about other browsers, but IE also responds to WWW_GetWindowInfo and WWW_Activate messages, which you could use to enumerate open windows and their URLs, and then activate a particular window.
I have a Native WinApi C++ Application that finds media(.wmv, .mp3 etc.) files in a specified directory & creates random playlists. The first time the application is run(& only the first time) I want to prompt the user to specify a 'home' directory that the Application will always check for media files & create a playlist from.
My Problem: I dont know of a way how I could determine when the Application is run for the 1st time?
Is there a standard way, maybe a Win32 function that I can use to detect when the Application is run for the 1st time?
Some ideas I have come up with are: (but they seem like hacks or overkill(installer idea))
The application .exe is 322kb(which is tiny & doesn't require an
installer right?) in size so I could create an installer (I was
thinking if someone is installing the application then I know its the
first run & I can prompt them then).
I could have a text file(or xml) called appData.txt & have the 1st
line where I store the home path directory. So "home_path=undefined",
on application run, I look in the text file, if the home_path ==
undefined then I prompt them to specify a home path if its not undefined then I read that directory for media files.
Any ideas of how I can determine when my Application is run for the very first time?
In the installer you could create a registry value for your program.
Then when you start your program, check the registry value.
When you run the program for the first time update that value to so you know it's been run already.
I would use the text file because you are going to have to store the user's directory somewhere anyway, might as well use it for first run detection as well. It has the added bonus that if the file is deleted, you will know that you have to prompt the user again since you no longer know what their home directory is.
You can set some registry value when your App runs for first time and check it on every run. If it is already set then App was already run. If not - set it.
Create a log file on first run. If it exists, then it's not the first time.
try
{
// open log.txt
// do second time run logic here
}
catch(file does not exist)
{
// create log.txt
// first run logic here
}
I wrote this C++ application that needs to check an INI file (“preference.ini”), and eventually modify it (e.g. if the user does not want to see the introduction form anymore). I created it in WinXP, and it works fine on the system where I compiled it (in many locations, including “Program Files”).
Problem:
In Win 7, it works fine if I put the complete program folder under “C”:\” (e.g. “C:\MyProgram”), but if I put it in “C:\Program Files (x86)\MyProgram”, it just retrieves some mysterious data (values not present in my INI file). When I change some settings and save them to file, it (apparently) save the changes (get no errors, but the changes are not there when I go and open the file...
I had some similar issue on a system with another WinXP system (not the one where I compiled it.
I used 'getcwd' to define the path at runtime, and I verified that it is getting it right, even under "Program Files (x86)":
char currentPath[MAXPATH];
getcwd(currentPath, MAXPATH);
std::string licensePath(currentPath);
licensePath.append("\\dat\\preference.ini");'
Any ideas? Thanks in advance for your help.
The answer is as #Kirill has already said - Win7 won't let you write data into Program Files unless you have higher than normal permissions (Run as Administrator). In this case it may be redirecting your file writes so that they still apear to work, but the data itself is not stored in Progam Files.
To add to his answer: In general (unless you want to run your app as an administrator), you should not write any program data to the Program Files folder.
Application settings should be stored in one of the AppData folders. You can get to your user's appdata manually by going to your start menu Search box (Vista/Win7) and typing %appdata%.
To find this location in your code, use SHGetFolderPath with CSIDL_APPDATA (current user) or CSIDL_COMMON_APPDATA (all users).
It could be related to that Windows use virtualization of the file system. You could read here about it. Check if your INI file is located in <root>\Users\<User_name>\AppData\Local\VirtualStore.
Seems to me that the licensePath: getcwd() + "\\dat\\preference.ini" is not what you would expect.
Log this value (console or in a log file) and see what exactly is the value of licencePath is when running you program from different folders.
This article is about game development but has the best description of how and why this happens that I've been able to find
http://msdn.microsoft.com/en-us/library/ee419001(VS.85).aspx
This paragraph from the article describes what is happening most likely -
Attempting to create or write a file
or directory under a folder which does
not grant write permission to the
process will fail under Windows Vista
if the application does not have
administrative privileges. If your
32-bit game executable is running in
legacy mode, because it did not
declare a requested execution level,
its write operations will succeed, but
they will be subjected to
virtualization as described in the
section "UAC Compatibility with Older
Games" later in this article.