C / C++ / MFC

Re: How can I program so that the application only respond to mouse events?

16-Mar-03 3:31

Can I block keyboard events such as keypress or key down of any key in a program?

The program will be controlled by a mouse only.

Thanks

JW

DJ

Nish Nishant16-Mar-03 4:47

Nish Nishant

16-Mar-03 4:47

You can try one of these methods :-

(1) Handle all the keyboard messages and dont call the default handler

or

(2) Set a local keyboard hook ( WH_KEYBOARD ) and dont call the next hook; and return a non-zero value

Nish

Author of the romantic comedy

Summer Love and Some more Cricket [New Win]

Review by Shog⁹
Click here for review[NW]

How can I write a program in VC++6 such that only ONE instance of

DengJW16-Mar-03 3:22

Re: How can I write a program in VC++6 such that only ONE instance of

16-Mar-03 3:22

this program can be run at any time?

I customized media Player based on Windows Midia player control. However, the media player could not be run exclusively, that means if I try to run two of them, each one will open a media file and play simultaneously.

How can I program so that only one media player program can run at any time? Like using Windows MEdia Player, if you try to run a second movie file, the Media Player will close the first media file and turn to start running the second media file?

The platforms are VC++6 and WIndows 2000 Pro.

Appreciate your help!

JW

DJ

⁷³Zeppelin16-Mar-03 3:57

Re: How can I write a program in VC++6 such that only ONE instance of

16-Mar-03 3:57

See the following articles:

http://www.codeproject.com/useritems/Single_Instance.asp

http://www.codeproject.com/cpp/singletonapp.asp

http://www.codeproject.com/cpp/csingleinst.asp

http://www.codeproject.com/cpp/avoidmultinstance.asp

http://www.codeproject.com/csharp/cssingprocess.asp

Florin Ochiana16-Mar-03 11:42

Florin Ochiana

16-Mar-03 11:42

Excerpt from MSDN:
You will find this in the file msdn_mfcfaq50.htm (MFC FAQ).

---------------
How do I limit my MFC application to one instance?

Look at the Microsoft C++ sample ONETIME.

In brief:

const char* MyMainWndClassName = "MyMainWndXQW"
BOOL CMyApp::InitApplication()
{
// Call base class. Default version does nothing.
CWinApp::InitApplication();
WNDCLASS wndcls;
// Start with NULL defaults.
memset(&wndcls, 0, sizeof(WNDCLASS));
// Get class information for default window class.
::GetClassInfo(AfxGetInstanceHandle(),"AfxFrameOrView",&wndcls);
// Substitute unique class name for new class.
wndcls.lpszClassName = MyMainWndClassName;
// Register new class and return the result code.
return ::RegisterClass(&wndcls);
}

And:

BOOL CMyApp::FirstInstance()
{
CWnd *PrevCWnd, *ChildCWnd;
// Determine if another window with our class name exists.
PrevCWnd = CWnd::FindWindow(MyMainWndClassName, NULL);
if (PrevCWnd != NULL)
{
// If so, does it have any pop-ups?
ChildCWnd=PrevCWnd->GetLastActivePopup();
// Bring the main window to the top.
PrevCWnd->BringWindowToTop();
// If iconic, restore the main window.
if (PrevCWnd->IsIconic())
PrevCWnd->ShowWindow(SW_RESTORE);
// If there are pop-ups, bring them along too!
if (PrevCWnd != ChildCWnd)
ChildCWnd->BringWindowToTop();
// Return FALSE. This isn't the first instance
// and we are done activating the previous one.
return FALSE;
}
else
// First instance. Proceed as normal.
return TRUE;
}
CMyApp::InitInstance()
{
if (!FirstInstance())
return FALSE;
// ...
}

null@diku.dk, programmer.tools, 6/19/95
See also Win32 SDK Knowledge Base article Q124134 ("Allowing Only One Application Instance on Win32s") and Jeffrey Richter's Advanced Windows NT, chapter 7, "Prohibiting Multiple Instances of an Application from Running: The MultInst Sample Application" (available on the MSDN Library CD).

null@diku.dk, email, 8/8/95
Update—these were posted to mfc-l:

I have each InitApplication() create a semaphore. If GetLastError() returns ERROR_ALREADY_EXISTS then I know that some other application is already running and has gotten that far, so I bail.

Yourapp::InitInstance()
{
hMutexOneInstance =
CreateMutex(NULL,TRUE,_T("PreventSecondInstance"));
if(GetLastError() == ERROR_ALREADY_EXISTS)
bFound = TRUE;
if(hMutexOneInstance)
ReleaseMutex(hMutexOneInstance);
return (bFound == TRUE) ? FALSE : TRUE;
}

mcontest@universal.com
There is a nice section in Jeffrey Richter's book Advanced Windows NT about this. Essentially, it uses shared data segments between processes.

In your main file, add:
#pragma data_seg(".SharedData")
LONG nUsageCount = -1;
#pragma data_seg()

In your Application's InitInstance(), call:
InterlockedIncrement ( &nUsageCount );

This function returns the incremented value of the variable. If it is nonzero, you know that you are not the first App.

In your Application's ExitInstance(), call:
InterlockedDecrement( &nUsageCount );

In your .DEF file, have the following lines (note that the segment name you give here should match the one in the application's main file):
SEGMENTS
.SharedData shared

abalakri@us.oracle.com
You'd better use one of the built-in synchronization methods. See the Win32 Knowledge Base article Q124134, "Allowing Only One Application Instance on Win32s," for a sample of using a memory-mapped file for synchronization. It doesn't include starting the previous instance, but if you detect that you're not the only one running, it should be pretty simple: If CreateFileMapping fails, try to find the previous instance from the window class name. If it's not found, sleep for a while and start over (with CreateFileMapping). In this way, either you will find the other instance when it gets around to creating its window or CreateFileMapping will eventually succeed. The advantage of using CreateFileMapping instead of CreateObject is that it also works on Win32s.

nuj@kruger.dk
Note There's a sample of this that was contributed by john@jing.com (John Xu) called onetime4.zip that is in the MFC FAQ archive.

-----
We are what we repeatedly do. Excellence, then, is not an act, but a habit.

Thanks to John and Florin. I am reading up the docs. Do you have any more suggestions on

DengJW16-Mar-03 15:41

Thanks to John and Florin. I learnt a lots from your posts and got my thing done.

16-Mar-03 15:41

how to implement or integrate them into an existing VC++6 Diaglogue based program so that I can use some of the ActiveX Controls?

THanks

JW

DJ

DengJW16-Mar-03 23:16

16-Mar-03 23:16

Really appreciate your help!

JW

DJ

Coordinate Conversions

georgiek5016-Mar-03 2:56

16-Mar-03 2:56

I want to determine if the mouse is in a certain region, I am using GetCursorPos to get the mouse cursor position and GetWindowRgn to get window region.

I know that the former is in screen coordinates and the latter in window coordinates. Which function should I use to convert one of the two values to make them common so PtInRegion will work?

Brian Shifrin16-Mar-03 3:04

Brian Shifrin

16-Mar-03 3:04

ScreenToClient & ClientToScreen

georgiek5016-Mar-03 3:07

16-Mar-03 3:07

I don't quite understand your answer but I have tried those methods and they don't work, I think it's because the region is in WINDOW coordinates and not client as stated in MSDN.

⁷³Zeppelin16-Mar-03 3:13

16-Mar-03 3:13

I would use DPtoLP() for which you can find more
information here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/cordspac_6rqo.asp[^]

georgiek5016-Mar-03 6:28

16-Mar-03 6:28

Thanks, can you post some example code, I still don't understand which coordinates need to be converted and the relationship between logical coordinates and screen/client coordinates.

The a preview of my functions:

<br />
GetCursorPos(&pt);<br />
<br />
GetWindowRgn(hwnd, hRgn);<br />
<br />
if ( PtInRegion(hRgn, pt.x, pt.y) != 0 )<br />
   ...<br />
else<br />
   ...<br />

⁷³Zeppelin16-Mar-03 7:03

16-Mar-03 7:03

When you do any type of drawing, for example LineTo(), MoveTo(), etc... that involves the device context (DC) - these functions assume you are passing logical coordinates. These functions are members of the device context (DC) which has its own set of coordinates (the logical coordinates). Your mapping mode (a property of the DC) determines the units of measurement when you draw something.
The coordinate data received from the mouse messages is, however, not in logical coordinate form. Thus, points passed to OnLButtonDown(), OnMouseMove(), etc... are in DEVICE UNITS, that is pixels. These are measured relative to the top left corner of the client area. These are called client coordinates. When you call InvalidateRect() the rectangle is assumed to be defined in terms of client coordinates.
If your mapping mode is MM_TEXT, then client coordinates and logical coordinates in the device context are both in units of pixels and so they are the SAME, as long as you don't scroll the window.
Thus to properly convert between coordinates there are two things you need to do:

1. Convert client coordinates that you get from the mouse to logical coordinates

2. Convert any bounding rectangles (regions, etc...) back to client coordinates (if, for example you want to call InvalidateRect())

Thus you could do something like this in OnLButtonDown() or OnMouseMove() handler:

<br />
void CMyView::OnLButtonDown()<br />
{<br />
     CClientDC aDC(this);    // Create a DC<br />
     OnPrepareDC(&aDC);      // Get origin adjusted<br />
     aDC.DPtoLP(&point);     // convert point to logical<br />
<br />
     // your code here<br />
}<br />

In the above, you obtain a DC for the current view by creating a CClientDC object and passing 'this' to the constructor. The advantage of CClientDC is that windows automatically releases the DC when the object goes out of scope. This is necessary because there are a liminted number of DC's in windows.

For a geometric shape (Rgn, Rect) I suppose you could try the following:

<br />
CClientDC aDC(this);<br />
OnPrepareDC(&aDC);<br />
<br />
CRect aRect = /* Code to construct rect goes here */;<br />
aDC.LPtoDP(aRect);<br />
InvalidateRect(aRect);<br />

<br />
CRgn aRgn = /* Code to create region */;<br />
aDC.LPtoDP(aRgn);<br />
<br />
// Your code here....<br />
if ( PtInRegion(hRgn, pt.x, pt.y) != 0 )<br />
   ...<br />
else<br />
   ...<br />

Thus, the coordinates should be properly converted...

Hope this helps.

georgiek5016-Mar-03 7:41

16-Mar-03 7:41

Ok, explanation understood...I'm coding in Win32 so the code I didn't quite get fully. (Sorry for not stating this fact)

georgiek5016-Mar-03 14:38

16-Mar-03 14:38

Just wanted to let you know I solved my problem and all it took was a ScreenToClient and one more little thing that MSDN forgot to mention thus leading to wasting of 15 hours of Yahooing and countless cigarettes:

GetWindowRgn(hRgn, pt.x, pt.y) is supposed to obtain a copy of a region but nowhere does it state that you should have created some kind of region with this handle already!!!!!!!!!!!!

Luckily I came across this on some website with some code example in a programming language I have never seen before that said to create a region first (doesn't matter what kind) and then call the function...I am really curious as to why MSDN thought this to be unimportant enough to mention???

Now does this create a resource leak? Who knows with this region stuff?

Thanks again for the help.

⁷³Zeppelin16-Mar-03 15:51