[RESOLVED] mouse problems

I have a form in my program with FormBorderStyle: None. Its Size is 1245 x 662.

On my form I have a PictureBox control called picGame. The picGame control's SizeMode
attribute is StretchImage; the actual image size is 1384 x 768.

In my code, I have the following Sub:

Code:

---

    Public Sub DrawBoard()
      _gameGraph.DrawImage(My.Resources.Screen_Player, New Rectangle(0, 0, 1384, 768))
      _gameGraph.DrawImage(My.Resources.Button, New Rectangle(652, 408, 100, 26))

        RaiseEvent boardUpdated(_gameField)
    End Sub

    Public Event boardUpdated(ByVal bmp1 As Bitmap)

    Private Sub gameUpdate(ByVal bit As Bitmap) Handles Me.boardUpdated
        Me.StartPosition = FormStartPosition.CenterScreen
        picGame.Image = bit
        picGame.Refresh()
    End Sub

---

The program "adds together" all the bitmaps drawn in the DrawBoard sub and then displays it as
a single image at runtime using the gameupdate Sub. This has worked well for me in the past,
placing images with transparency perfectly, and very quickly, and with no flicker. I've
written an entire Chess program and Reversi program using this method, so I know it works.

My problem is this:

In my the MouseMove Sub associated with the picGame control, none of the e.X and e.Y coordinates
match with the screen coordinates of the bitmaps I've drawn.

In other words, I've put the button at coordinates 652, 408; this is where it looks good to me
on the screen. However, when I move the mouse, the actual location of 652, 408 -- according to
e.X and e.y is about 50 pixels off to the right and down. To add to the confusion, not every
control is off by the same amount. I mean, if they were ALL off by the same number of pixels,
then adjusting things would be easy; but, no, there's something weird going on here.

With Chess and Reversi, all the pieces are in very, very predictable positions. Yes, I
did have to adjust the clicking for each column and row, but it was no big deal... until now.

I'm not sure why this is, nor how to correct it, so that I don't have to do a 'special case'
scenario for each control I've drawn on the screen. Any ideas?

Nothing weird about it at all. The graphics co-ordinates are relative to the drawing surface. The mouse co-ordinates are relative to the form. If your picture box is offset from the top left of the form then the co-ordinates simply don't match.

In different events, you get coordinates in different frames of reference. Figuring out which frame of reference a particular set of parameters is in can be entertaining. However, there are a few PointToSomething methods that can be used to map a coordinate into a different frame of reference. I've already forgotten which frames of reference you are dealing with, though it sounds like dunfiddlin knows. In my case, when things didn't end up where I expected, I'd have to go rooting around in the documentation to figure out what frame of reference any particular point was in.

The picturebox is docked to the form. The form is centered into the screen via Me.CenterToScreen. I can't seem to figure out how to determine the mouse's REAL coordinates vs. what it's showing - in other words, if the control is located at 50,50 then the mouse being at 50,50 should click on it... rather than the mouse being at something like 80,90 to click on the same control.

How do I fix this???

Well stop using e.X and e.Y to start with. These are relative to the control in which the event is raised and in no way reliable for absolute positioning. Remember also that the co-ordinates you give (652, 408) are for the top left corner ie. 0,0 for the control so even if you have the exact co-ordinates, you still need a degree of offset to ensure that you are in a position to affect the control. And,, of course, the fact that the PictureBox image is set to Stretch will also distort the co-ordinates further. Co-ordinate location is difficult enough at the best of times and largely a matter of trial and error unless you have a fantastic memory for what raised which event. The combination of factors in this case makes it nigh on impossible to give you a 'fix'.

However, I would probably start by drawing directly onto the form rather than interposing a bitmap and picturebox (and two whole new sets of relative positions) into the equation. At least you can be sure in those circumstances that anything you draw is where you draw it!

I'm not sure drawing directly on the form is possible for me. I could place picturebox controls directly, and the coordinates of those controls are exact; however, the picturebox control doesn't support transparency. So unless I make all my controls rectangular (boring) or else place a rectangular 'background' behind the button (doesn't always line up, often looks terrible), then I'm stuck.

I have ovals, triangles, and rectangles with rounded corners. So far as I know, unless I resort to the tricks listed above, getting my controls on my form -- with the transparency intact -- is only possible the way I'm doing it.

You could make these into fully fledged custom controls. Then you'd be able to use them in just the same way as any other control.

Ok. I've downloaded a couple of tutorials & examples of custom controls in various shapes; I'll see if this is more to my liking. My questions at the moment: A). Can I duplicate the results?; B). Will the results DO what I want? For the moment, the jury's out, until I play with the code I've downloaded a bit. If so, you'll have saved me an IMMENSE amount of trouble, as my current code's 'modification' of the e.x & e.y coordinates is spotty at best.

Thanks for your suggestion. I'll let you know how it turns out.

Well, none of the code I downloaded worked, I'm not sure why. But as I was fiddling around, I came across a Rectangle control in the toolbox - which handles transparency perfectly. Now, the redraw of these rectangles isn't as smooth as redrawing the graphics the way I was doing it, but I was able to place controls and use their mousehover/mouseleave/mouseclick events without having to 'track' where the mouse coordinates are. There's probably a way to get the EXACT x & y coordinates for such as system as I was using before, but for this particular program, I'm happy with the rectangles. Not as elegant, but IT WORKS - which is the main thing.

I just wanted to pass this on, in case anyone else ever has this problem.

If your picture is 1024x768 and your window is 800x600 and you stretch your picturebox to fit, everything and anything connected with this form is going to go to S*** really, really fast. You must either make your window the size of your picture or vice-versa. When the background image and window size are the same, the e.x and e.y coordinates correstpond on a 1:1 basis. OTHER controls may be sized, but the main, background image - the one that's being redrawn in the example below - is the one that MUST be sized at the same size as the window.

I decided to go back to this method, as the Rectangles' redraw was very clunky and slow. When I redid this, I thought about the problem I'd been having before I started this thread, and made a test. When the test worked perfectly, on the first compile, I knew I'd come across something of interest.

My only remaining complaint is to Microsoft: Why the @#$%&! didn't you make the PictureBox controls handle transparency???

Anyway, Thanks for all your help.

Code:

---

    Public Sub DrawBoard()
      _gameGraph.DrawImage(My.Resources.Screen_Player, New Rectangle(0, 0, 1384, 768))
      _gameGraph.DrawImage(My.Resources.Button, New Rectangle(652, 408, 100, 26))

        RaiseEvent boardUpdated(_gameField)
    End Sub

    Public Event boardUpdated(ByVal bmp1 As Bitmap)

    Private Sub gameUpdate(ByVal bit As Bitmap) Handles Me.boardUpdated
        Me.StartPosition = FormStartPosition.CenterScreen
        picGame.Image = bit
        picGame.Refresh()
    End Sub

---

Just about every statement in this is wrong, misleading or unhelpful. The PictureBox does handle transparency, just not in the way you want it to. Microsoft are not in any way at fault here. The PictureBox is something of an extra luxury item for those who can't or won't learn GDI. It is not in any way necessary for the display of images nor is it designed for the purpose that you require of it.

Yeah & every programming language with commands longer than 3 chars is an extra luxury for those who can't or won't learn assembly. Get real dude.

I'm not certain how my statements are "wrong" or "misleading." I'm reporting what I actually experienced in VB2010. When I put a picturebox control on my form, set docking to full, and had the picture streched and form smaller than the actual picture, the picture's mousemove e.x and e.y statements were nowhere near where I'd put the images on the form. In other words, in my DrawBoard section, I had a control 100 pixels wide and 50 pixels tall I'd placed at 200, 100. When I did my mousemove, I expected that when I placed the mouse between 200, 100 and 300, 150 that I'd be between the upper left and lower right bounds of the control. Nope, nope, and nada. I had to adjust each and every x and y coordinate separately.

When I did my Othello (Reversi) game, this was no problem, as the x and y coordinates for each square were very, very predictable, and easily adjusted. Here, where there's controls all over the screen, this wasn't practical.

So when I recreated the image to be the exact size of the form - now 800 x 600 - each control I've placed on there is exactly right; now the mousemove e.x and e.y coordinates work properly. There must be SOMETHING in the stretch or dock (or both) that makes this effect.

As far as the Picturebox controls, I've placed .PNG images in them and tried everything I could to get the backgrounds to be transparent. I can do transparency on the MAIN Picturebox control, the one that's the background picture for the form (and thus get rounded corners or unusual shapes for the form), but to do so for the controls ON the background just doesn't work.... unless, of course, you want your desktop showing through around your form's graphic buttons...

BTW, I started out with BASIC on a Commodore PET/CBM, then graduated to IBM and Microsoft's QuickBASIC, back under DOS v6.22. I eventually learned Assembly, C and C++ (and the joys of object-oriented programming). It wasn't until about four years ago that I picked up my canvas and brush again to start writing programs under VB.NET's platforms; I haven't tried any C/C++ windows programs yet, but all the Visual Basic ones I've done have worked very, very well. For most of the graphics, it's been a matter of finding existing code that was close to what I wanted, copying that code, and then transforming into what I wanted. As I've done this, I began to learn not just HOW, but WHY certain commands worked or didn't. I haven't had time to learn GDI, although I'm interested. Perhaps, once this batch of five or six programs is done, I'll take some time off & learn it, but until then....

Oh, I loved the C/C++ libraries; they reminded me a lot of Assembler's ability to load libraries. You see, once I learned how to do specific functions, i.e., moving the cursor, outputting text, etc., I put them into a library which I then included with each project. What I ended up with was virtual commands that looked A LOT like their BASIC counterparts, and worked the same way. All I had to do was to call the function from my program, pass the parameters, and voila! Instant code! That way, I didn't have to lug around my notebook to remember how to do each function. My final project was a 'Chat' program between two IBM PC's (8086 architecture) using a serial board I'd built. The program was in color, had sound, and had two windows, one for each user. The code was so far beyond the other students that the instructor accused me of perjuring someone else's work, and I had to prove myself by showing my full code.

Also, I think (IMHO) that it's better, in these forums, to keep to CONSTRUCTIVE criticism rather than DESTRUCTIVE. I mean, posting sample code of how to do something in GDI would have been preferable to the acerbic remarks. Thanks again, folks. Keep on programming!!