[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?
Re: [RESOLVED] mouse problems
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
Re: [RESOLVED] mouse problems
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.
Re: [RESOLVED] mouse problems
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.
Re: [RESOLVED] mouse problems
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!!