Avoid second program call

To All,

Additional info can be found at this link.
http://support.microsoft.com/support...s/Q97/9/25.ASP

Cecil

------------------

[Eric Pearson]

Jason --

> You may want to let him know the problems
> you found w/ his code.

We've corresponded. Karl is a good guy... The AttachThreadInput method is (as far as I know, anyway) the best method that is currently available. Karl is still working on the problem, as am I.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

Eric,

Thanks. Now I know what's going on. Lance wasn't all that clear to me. I wasn't questioning the FindWindow() function. That was obvious. Great job!!

Cecil


------------------

Eric,

Hmmm...well...I guess my original suggestion wasn't such a good idea . Sorry!

Regards,

Jason

P.S. You may want to let him know the problems you found w/ his code.

------------------

[Eric Pearson]

The SwitchToThisWindow API function still exists, but its behavior has been changed. All it does now is blink the task bar button, just like SetForegroundWindow.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Semen Matusovski]

Eric --
I have russian beta - build 2195, dated dec, 1999.
We expect official "release" in June only.
Do you want to say that this function is excluded from user32.dll or it changed behavior ?




------------------

[Eric Pearson]

Jason --

There are a number of problems with the AttachThreadInput technique on Karl's site. The biggest problem is that it cannot steal the foreground from a console application. In fact, if a console app (or a DOS app, or a command prompt window...) has the foreground, using AttachThreadInput can cause major problems, including app and Windows lockups. Another problem is that AttachThreadInput cannot be used by a console application, such as those produced by PB/CC. Another problem is that Karl's routine cannot give the foreground to a window that your app does not own, and there are other problems too.

Semen --

The SwitchToThisWindow API does not work in the release version of Windows 2000. It worked during the early and middle beta versions, but it was disabled at the last minute.

I believe you'll find that it blinks the task bar, just like SetForegroundWindow.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Semen Matusovski]

Guys --
I know that Lance doesn't like non-documented functions, but this sub (SwitchToThisWindow hWnd) works in all existing Windows (95/98, NT/2000)

Declare Function MySubCall(ByVal p1 As Long, ByVal p2 As Long) As Long
Sub SwitchToThisWindow (hWnd As Long)
   Static SubrAddr As Dword, lResult As Long
   If SubrAddr = 0 Then _
      SubrAddr = GetProcAddress(GetModuleHandle("user32.dll"), "SwitchToThisWindow")
   Call Dword SubrAddr Using MySubCall&(hWnd, %True) To lResult
End Sub

------------------

If you really want to get around the W2K SetForegroundWindow issues, check out Karl Peterson's web site ( http://www.mvps.org/vb/ ). Under the Samples section there's a package called ForceFore.zip that contains Win32 API code in VB to force your window into the foreground in W2K.

Personally, I don't recommend this. I like the "flashing" toolbar window style in W2K; it's really annoying in NT to accidentally close a message box that pops up out of nowhere when I'm in Word and I press the Return key . But if you want the functionality then check out Karl's site.

Regards,

Jason Bock

------------------

[Eric Pearson]

Cecil --

> I beg to differ with you on what you said
> about the snippet above

Lance is correct about the SetForegroundWindow API, except that I believe he meant to say "98" not "NT". Microsoft has "neutered" the SetForegroundWindow API in Windows 98 and 2000, and all future versions of Windows. Here is an MSDN page that explains the changes...

http://msdn.microsoft.com/library/ps...ndows_1eev.htm

And he is also correct in saying that you must use a unique class name for the snippet to work correctly.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited April 04, 2000).]

Lance,

OOOOOOch!! Did you reaaaaaaly read all the messages in this thread? I realize that I'm still somewhat new to Windows programming but I beg to differ with you on what you said about the snippet above. YEEEEEES, NT4 runs this code just fine, haven't tried W2K. In fact, the C++ code came straight from MSDN sample, I just ported PB. As a matter of record when looking for a way to do something, I check my books, then the PB forum, MSDN and some other resources that I have and lastly post a message in the PB forum.

Now I'm NOT naive enough to take anything to record until I test it, even what M$ says. In fact, I found another code frag dated 2-2000 that uses similar code on MSDN, albeit in VB6. Maybe I have missed something here. Please enlighten Me. Is there really ANYTHING 100% absolute in Windows, I don't think so. Just stick around until the next SP release and see!!!

Cecil

------------------

[Lance Edmonds]

JFYI, SetForegroundWindow() does not work like that in NT and Windows 2000 - Microsoft changed the behavior of this API so that it only flashes the taskbar button unless your process launched the app or owns the target window (and there are some other exotic circumstances that it may work with) - http://msdn.microsoft.com will provide more info on this if you are so inclined to research this further. There are some work-arounds but none are guaranteed to be 100% reliable in all circumstances.

Also, your FindWindow() code relies on your target app's window having a unique class name - again, this cannot be 100% guaranteed (although it may be 99.9% ).



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Another option, SDK style. This code obviously goes in WinMain and if existing app is minimized, brings it to forefront.

  hPrevWnd = FindWindow(BYVAL wndClass.lpszClassName, BYVAL 0)
  IF ISTRUE hPrevWnd THEN
    IF ISTRUE IsIconic(hPrevWnd) THEN ShowWindow hPrevWnd, %SW_RESTORE
    SetforegroundWindow hPrevWnd
    FUNCTION = 0
    EXIT FUNCTION
  END IF

Cecil
------------------




[This message has been edited by Cecil Williams (edited April 03, 2000).]

Thank you Semen!

Thats it...

------------------

[Semen Matusovski]

Gerd --
As I understand, MSDN recommends Mutex, something like this

#Compile Exe
#Dim All
#Register None
#Include "WIN32API.INC"
Function PbMain()
   Local hMutex As Long, hDlg As Long, PrgName As Asciiz * %MAX_PATH
   PrgName = "Any unique name" ' Important
   hMutex = CreateMutex(ByVal %Null, 0, PrgName): _
      If hMutex = 0 Then Exit Function ' Error in Mutex
   If GetLastError = %ERROR_ALREADY_EXISTS Then _
      MsgBox "Already running": Exit Function
   Dialog New hDlg, "First Instance", , , 100, 100, %WS_SYSMENU To hDlg
   Dialog Show Modal hDlg
   CloseHandle hMutex ' Possible to delete
End Function

PS. I wrote "any name" (Win32.Hlp keeps silence), but I noticed that Mutex, for example, doesn't like \

[This message has been edited by Semen Matusovski (edited April 02, 2000).]

I would like to avoid when my program is running, a second call of this application (under Win its possible to start the same program until you are running out of memory).
Under DOS I solved the problem with the Multiplex Interrupt.
What should I do under DLL6.0 or VB6.0 ?