You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
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 ?
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).]
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).]
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% ).
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!!!
> 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...
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.
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
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 --
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 ?
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.
> 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.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
). 
. Sorry!
Comment