Announcement

Collapse
No announcement yet.

Avoid second program call

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    To All,

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

    Cecil

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

    Leave a comment:


  • Eric Pearson
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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


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

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

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

    Leave a comment:


  • Eric Pearson
    replied
    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>

    Leave a comment:


  • Semen Matusovski
    replied
    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 ?




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

    Leave a comment:


  • Eric Pearson
    replied
    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>

    Leave a comment:


  • Semen Matusovski
    replied
    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)

    Code:
    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
    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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

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

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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

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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Another option, SDK style. This code obviously goes in WinMain and if existing app is minimized, brings it to forefront.

    Code:
      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).]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Thank you Semen!

    Thats it...

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

    Leave a comment:


  • Semen Matusovski
    replied
    Gerd --
    As I understand, MSDN recommends Mutex, something like this

    Code:
    #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).]

    Leave a comment:


  • Guest's Avatar
    Guest started a topic Avoid second program call

    Avoid second program call

    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 ?
Working...
X