[RESOLVED] Open several files using Command

[Fenrir]

[QUOTE=Bonnie West;4375555]It's included in the Windows SDK. But if you don't want to download it, you can generate GUIDs instead via code.
I've never used GUID, so excuse me if I ask for stupid questions. I'd like to create a new one via code, using the CreateGUID from your link like this:

If CreateMutexW(lpName:=StrPtr(CreateGUID()) Then

won't each new instance create a new univocal GUID for itself?

If it's so, I think the condition will always fail. I should always use the same GUID (declaring it as Const), but doing like this, there's the riks another app uses my same GUID? Well, what are the advantages of this practice if all my assumptions were true?

You can simply pass """" & CurDir$ & """ " & Command$ to the previous instance. The first instance should then prepend the current directory of the second instance to any relative path in the command line.

And what if user doesn't use relative paths? I'd have (for example) a variable that contains this:
newCommand$ = """C:\Program files\my_exe_dir"" ""C:\documents and settings\user\desktop\file.ext"""
Now, if I try to execute the Open statment:

Open newCommand$ For Input As #1

won't I should receive an error??

Well, that's true. That is why most modern computers can run a lot more applications than ever before. But, what happens if a particular user had too many processes going on at the same time, especially with an app that constantly reads/writes to disk (video capture perhaps)? What if that user happened to multiple-clicked or double-tapped on the Enter key while opening your single-instance app in the middle of a video-recording session? Suppose that user wasn't using a SSD but instead was recording to a regular HDD. What do you think would happen to the FindWindow call?

Don't you think that if also my application has to keep always open a file to read/write the hWnd of the first instance, this may slow or damage the HDD?

Don't get me wrong, but I think you ought to know what you're getting yourself into with that code. I suggest that you should at least read Why FindWindow doesn't work in order to understand why looping with FindWindow like that is a bad idea. The following is a scenario presented in that article that highlights one of the pitfalls of FindWindow. Of course, if your app doesn't need to be very robust, then FindWindow is good enough most of the time.

These are cases at the borders of reality O_O A more concrete case maybe you find another program that uses the same Caption of your own. But, reading the article, I discovered a possible solution: the loop goes on until (hPrevWnd = 0) Or ((hPrevWnd <> 0) And (DataRecived = False)), where DataReceived is a variable that changes to True when the SendMessage will successfully processed by the first instance.

Pass "ThunderRT6FormDC" rather than vbNullString to FindWindow to make the search more specific.

I was reading that a ClassName is assigned for registered applications only (even though I don't know what it means). Are you sure that will it work?