You are here:

C++/Program for co-ordination of mouse


Hello sam,
         I will be pleased if u give me a program for c++ which displays mouse pointer on the screen...i.e. like normal windows....i.e. it should work like normal windows in o/p of c++....i.e. clicking should be possible.....i just hope u got me properly.  u may even guide me as what to use for doing so.
         thank you.

Sam? Who is Sam? I am Ralph McArdell, not Sam.

I am a C++ expert however.

You are not going to like my answer, and I am not sure that I do, in fact, get you, and as such I am not sure what sort of code would be of use.

C++ has _no_ support for GUI like things, including devices such as mice and their graphical representations such as mouse pointers on screen. For that you need to look to operating systems (such as Microsoft Windows or Apple Macintosh), large sub systems installed as separate parts of a system (like the X window system popular with UN*X and Linux systems), or even some graphics libraries for non-graphical operating systems (for example various libraries contained mouse support for use with MS-DOS). Or you do it all your self from scratch.

You do not say what hardware and software (e.g. operating system) you are using. You mention "normal windows" - do you mean windows on your MS Windows desktop? If so then you should not need to do anything to display the mouse pointer - you should have one already. All your application has to do is process the mouse messages it is sent and maybe change the mouse cursor (pointer graphic) over various areas of your application's windows if necessary. Of course you can do things with the mouse pointer - such as hide it and show it. The exact way you do these things will depend on what form your application takes - which frameworks or libraries you are using or none at all (just using the Win32 API functions). I shall list some of the underlying Win32 API functions and messages here, and you can look them up on the MSDN library site (at and select library) if you are interested: ShowCursor - show or hide the cursor (aka mouse pointer), SetCursor and SetSystemCursor - set the cursor shape, SetCursorPos - moves the cursor to the specified position, mouse_event or (for Windows NT/2000/XP) SendInput - can synthesise mouse events such as movement and button clicks.


If you are confused as to how you go about using all these things then I suggest you read up on the form of a MS Windows program that uses windows and not the console, as they generally use a non-standard main function - called WinMain and have to perform certain start up actions then sit in a message loop receiving messages and passing them onto the appropriate window handling procedures until the application quits. You also have to build the program specifying windows and not console as the sub system - how this is done depend on your development tools.

Although I have given details of the MS Windows mouse handling, other GUI systems will be similar - using message or event loops, processing these messages or events etc... The details of course will differ.

Now let us assume you have a system that has no mouse driver but does have a serial port and some graphics library functions. You have a serial mouse connected to the system's serial port. What sort of things would need to be done to handle the mouse and display a cursor on the screen?

First off you need to read the serial port and interpret the data sent to it from the mouse - and no I do not know how to do this - suppose we had looked at this output determined how to decode the values sent by the mouse into movement and button state data.

This of course is best done on some sort of interrupt - but as the port is supported by the system let us assume collecting and buffering serial port input is done for us by the serial port driver. In C++ we can open the port and read it as a file input stream. In fact you can do this in a MS Windows NT/2000/XP console program with a serial mouse - just connect it to an unused serial port - say COM2 and open COM2 as the device 'file name'. We then sit in a loop waiting for mouse input - reading the input from the input stream. For each character read we would process it to decode it and then despatch the results to one of a number of handing functions: mouse move handler, button click handlers etc..

To draw the mouse on the screen we first need to set the number of mouse move units needed to move by one on screen pixel for both the X and Y dimensions - these mouse move units are sometimes called mickeys, and such as relationship might then be called MickeysPerPixel, possibly we require MickeysPerPixelX and MickeysPerPixelY. Next we need to define a starting position for the mouse pointer - so we require a function similar to the MS Win32 API function SetCursorPos.

Now to handle mouse movement we need to translate the mouse moves into pixel changes and when either or both the X and Y pixel positions change we call the relevant handler function. If MickeysPerPixelX and MickeysPerPixelY were 10 then for each 10 mouse movements in the X or Y direction the on screen mouse position changes by one pixel in either the X or Y direction - that can of course be + or - 1 pixel and one, the other or both X and Y coordinates may change. We add this change (or delta) value onto the current mouse pointer position to get the new pointer position.

Now the mouse move handler would have to update the position of the on screen depiction of the mouse - the mouse pointer graphic. This can be considered a sprite with the most forward position in the Z-order (i.e. it is always on top). A sprite is an "independent" graphic element that although rectangular has transparent areas allowing the background to show through. It may be animated, and has a Z-order position - i.e. a value that indicates which other sprites and other graphic elements will be considered behind or in front of it.

Now the position passed to the mouse pointer drawing function will be the position of the hop-spot - the part that represents where the mouse is considered to be. For a standard pointer this might be somewhere along the top in the middle. For a cross-hair target pointer it may be in the exact middle of the pointer graphic. In any case the mouse position together with the hot spot position are used to calculate the required position needed to draw the pointer graphic on the screen at the correct position - typically top left or bottom left. Of course you are free to define any conventions you like for the mouse position - this is just one common way things are done.

Of course all you have here is a program that can at the moment handle moving a mouse pointer over the screen and detect mouse button clicks. To be useful it also has to do other things - most likely it will have to do them even if no input is received from the mouse. This is a problem for our program as it stands as it waits until there is input from the mouse before doing anything. Maybe other inputs need to be handled - such as keyboard input, file input, network connections. Or there need to be other processing handled even if there is no user or data input.

Hope this has given you some help, although I still am not at all sure what it was you really wished to know. Please ask me another, more specific question if this one missed the mark and I did not get you! Sadly though that will have to wait until next weekend as I am away working during the week so am unable to answer questions.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.