[Closed] Mouse input window

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

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

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?

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?

Looks nicer now as well

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?

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

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?

Is there a way to NOT use the paint event?

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.