Mouse input window

#74

okay my second take on this GDI+ only method. There is something not right with using the picturebox as a drawing surface. Because if i substitute a panel for the picturebox, the dispose function calls without an exception. What i am seeing that is unwanted is a flicker when moved quickly. I have also set up a test painting onto a label control. this throws an exception if i try to dispose of the graphics in the paint handler. If i remove it, it functions normally without flicker.

I do not know if doing this creates a memory problem. if i perform the same dispose function in a label’s paint handler in Visual studio, I also get the same exception, so this must be a behaviour of the label control.

In VB i would solve flicker by setting the control double buffered property to true. This usually solves any redraw flicker. However i cant seem to set this in an MXS form and it appears that some controls like panel, even though they should inherit this class will still not allow you to set doublebuffered to true.

rollout dnpb "GDI+ paint" width:280 height:140
  (	
 	local acolor = dotnetclass "system.drawing.color"
 	 local abrush = dotnetobject "System.Drawing.SolidBrush" acolor.yellow	
 	 local anotherbrush = dotnetobject "System.Drawing.SolidBrush" acolor.Fuchsia
 	local pos1x = 65
 	local pos1y = 65	 
 	local pos2x = 65
 	local pos2y = 65	 
 	 dotnetcontrol pb "System.Windows.Forms.label" pos:[5,5] width:130 height:130 
 	dotnetcontrol pb1 "System.Windows.Forms.panel" pos:[145,5] width:130 height:130 
 	 
 	 on pb paint e do
 	 (	
 	g = e.graphics	
 	GDIsmoothing = dotnetclass "System.Drawing.Drawing2D.SmoothingMode"
 	 g.SmoothingMode = GDIsmoothing.highspeed		
 	 g.FillRectangle abrush 3 3 124 124
 	 g.FillEllipse anotherbrush (pos1x-15) (pos1y-15) 30 30		
 	)
 	
 	on pb1 paint e do
 	 (	
 	g = e.graphics	
 	GDIsmoothing = dotnetclass "System.Drawing.Drawing2D.SmoothingMode"
 	 g.SmoothingMode = GDIsmoothing.highspeed		
 	 g.FillRectangle abrush 3 3 124 124
 	 g.FillEllipse anotherbrush (pos2x-15) (pos2y-15) 30 30		
 	 g.dispose()
 	)
 	
 	on pb mouseMove sender arg do
 	(			
 		if arg.button==arg.button.left then
 		(			
 			pos1x = arg.x
 			pos1y = arg.y
 			pb.invalidate()
 		)
 	)
 	
 	on pb1 mouseMove sender arg do
 	(
 			
 		if arg.button==arg.button.left then
 		(			
 			pos2x = arg.x
 			pos2y = arg.y
 			pb1.invalidate()
 		)
 	)
 --	  
 	 on dnpb close do 
 	 (
 	 abrush.dispose()
 	 anotherbrush.dispose()
 	 )
 	 
  )
  createdialog dnpb

again, the more i experiment in max makes me think that for me, building a custom user control in VS is the best way to go…

#75

I’m not sure that I am seeing memory issues, just tried shutting everything down on my system and leaving it when I went for dinner. I didn’t have any more memory used then when I left. Just had the mouse hovering over the

This works now, I just don’t think that you had things in scope.

rollout dnpb "" width:140 height:140
(	
	   local acolor = dotnetclass "system.drawing.color"
	   local abrush = dotnetobject "System.Drawing.SolidBrush" acolor.yellow	
	   local anotherbrush = dotnetobject "System.Drawing.SolidBrush" acolor.Fuchsia
	
	   dotnetcontrol pb "System.Windows.Forms.Picturebox" pos:[5,5] width:130 height:130
	   
	   on pb paint e do
	   (	
		g = e.graphics
		GDIsmoothing = dotnetclass "System.Drawing.Drawing2D.SmoothingMode"
		g.SmoothingMode = GDIsmoothing.AntiAlias			
		g.FillRectangle abrush 3 3 124 124
		g.FillEllipse anotherbrush 50 50 30 30  
		-- this line is problematic!!	  
		g.dispose
	   )
	   
	   on dnpb close do 
	   (
	   -- as are these !!
	   abrush.dispose
	   anotherbrush.dispose
	   )
	   
)
createdialog dnpb
#76

Interesting that the forms.panel is showing the same problem that the imgTag is in Max. I have a much brighter out look on doing it with pictureBox at this point. Although I don’t have all the controls working agian I’m nto seeing any of the issues I was using setPixel. I thank you for pointing me down this path. I’m not getting flicker at all and the amount of code that I need to manage this has gone way down. I will report back with speed once I get it all working and see what kind of redraw that I’m getting compared to before and if it is in an acceptable range.

#77

ya i saw that and fixed it in my second post. the dispose() issue is weird though, im seeing differences between objects that i wasnt expecting. Good to know for the future. I will crack on with my dotnet user control and see what happens! cheers Paul, this is an interesting thread discussion! keep 'em coming!

#78

actually while i think about it, i found a great tool that is a WYSIWYG GDI+ editor. It helped me loads by showing the drawing options open to GDI+. it can generate the code for VB or C# but even if you can’t use this you can see the implementation enough to use it in Max dotnet. best of all, its FREE!!!

http://mrgsoft.com/products/GDIPlusArchitect/default.htm

#79

Here is the biggest issue that I have so far with doing this, undo isn’t working. When you scrub a control and you have undo on it is recording all the changes as your scrub so you need to undo many times to undo a single change.

Is there a way to stuff a specific event into the undo stack? So I could record the value of the parameters on mouse up and put that last value in the undo stack?

#80

Of course as I posted I thought of a solutions and it works.

In the on mouseDown even I just do


animate off (undo on (theDrivenparam=theDrivenParam))

Can any one think of anything cleaner?

#81

Looks nicer now as well

#82

OK another odd problem. I have three rollouts, if all rollouts are in the same subRollout, even in the modifier panel all is well…I think. If I extend my modifier panel to two wide or create a dialog that has two subs in it and load one rollout into one and two into another when one of the two that are together rolls up it tries to refresh all my pictureBox’s. It is odd as well that they get some crazy value passed to all of them. If I widen the modifier panel when they are in there it goes crazy as well. So is there a way to know that you don’t have to update?

#83

Hey Paul,

You can use the MouseUp event of the PictureBox. You might also need to use TheHold instead of the undo context, like:

TheHold.Begin()
DoSomething()
TheHold.Accept “Something”

Light

#84

I’m having some serious problems with this and speed updating the image. I don’t think that it is the pictureBox directly. What I have is a modifier with parameters that drive targets. When you move the joyStick it sets the value of the param and calls an invalidate and the paint event calls a function, passing the parameters into the function and sets the value of an System.Drawing.Rectangle to update the image in the joyStick. As the scene gets more complex the less the invalidate actualy gets called if there parameters are being passed. Wow, does this make any sense at all? In simple tests it works great, drop it in a scene that has DX shaders turned on and it barely updates at all.

Any suggestions or any one that wants to see code?

#85

Is there a way to NOT use the paint event?

#86

Hi Paul,

Your method is not much different to the way i have set up my joystick control - i will try to get it finished this week and i will test it in a scene to see if i get the same slowdowns as you. Though I’m not drawing to a picturebox and mine is a custom dotnet user control so it will be interesting to see how it fares compared to your MXS version.

I dont know if this is something you’ve already tried, but here is something i lifted from a C# forum about redraw methods - there are three and they might make a difference when calling multiple times -

Invalidate marks the control as in need of repainting, but
doesn’t immediately repaint (the repaint is triggered when everything else has
been taken care of and the app becomes idle).

Update causes the control to immediately repaint if any portions have been
invalidated.

Refresh causes the control to invalidate, and then update (i.e. immediately
repaint itself).

Most of the time Invalidate is sufficient, and advisable as you can do a bunch
of invalidations (either explicit or implicit) and then let the control repaint
itself when the app is idle. It is advisable to use Update or Refresh when you
want the control to immediately repaint because the app will not be idle for a
user-noticable period of time.

if you want to send me an example, PM me and i’d be happy to take a look.

#87

At this point I’m thinking that it isn’t the dotNetControl but the time it take to get values from the parameters, or some combination. It will be interesting to see what happens with yours. I only see it once I have it all connected up to a character, on it’s own or in a simple scene it works great. This is with only one control working as well. It isn’t like I have 10 of then trying to redraw all at the same time.

#88

Just tried


 senderArg.Invalidate()
 senderArg.update()

and it works, I had tried update() on it’s own and it was even slow but looks like you need to call the invalidate and then the update and it forces it. Thanks, reading that bit you found may have done it for me.

#89

I had the same issue with mine Paul, as invalidate only flags an update it queues it until the next redraw. This is usually pretty quick but on a fast updating user control you need it to do it immediately.

One issue with repeated repaint calls apart from speed is the flicker issue which i have come across also with this method. The flash is caused by the control erasing the image and displaying a blank background before it redraws the control. It is possible in dotnet to override the paint method to do nothing and perform the redraw elsewhere.

the other option is to use the SetStyle() method on a dotnet form to set the AllPaintingInWmPaint property to true. This will allow the form to disregard paint calls.

One option to try might be to try using this SetStyle method is possible, and move the redraw to the mouse move event rather than the paint event. At the moment the paint it is passing the redraw from the event to the other. The mouse event invalidates so it redraws, then sends the coordinates to the drawtarget function which invalidates and redraws again. perhaps you could avoid this double redraw by removing the paint call, doing all the work in the mouse move, sending that to the drawtarget sub and invalidate finally at the end when all the drawing is done.

The other property of use would most certainly be doublebuffering. with this, the image is built in memory instead on the control and then drawn on after onto the form. It takes the same amount of time to do this but dramatically reduces flicker.

#90

Well all sounds good. At the moment I’m not getting any flicker. How ever I would like to get rid of the paint event as I think it is the cause of other issues that I ran in to and have been trying to correct. The paint calls are being called when the dialog goes behind another dialog and then gets focus again. This causes some very strange results.

So, how do I go about painting without the paint event? I have been looking but not seen anything that jumps out at me at the moment. Also removing the paint event would simplify the code just that much more and give me a bit more control as to when painting happens.

Thanks for all the help. I’ll post a final working control when I know that it isn’t doing anything nasty.

#91

Looks like I will need “system.drawing.graphics” but not sure how to apply it with out the paint event.

#92

You can create a graphics object yourself by invoking the .CreateGraphics method of a control:

local g = MyControl.CreateGraphics()
g.FillRectangle brush rect
g.Dispose()

Cheers,
Martijn

#93

Doh, wasn’t looking there. Good stuff. I have it working as it is so I will poke around with this and see if I can simplify it later. So far it is responding quickly on my lap top without flashing and I have an old lap top. Unfortunitly I’m sitting in the emergency room with my wife trying to get work done. We might get free medical care in Canada but you sure do have to wait for it, 6 hours+ so far today.