Mouse input window

#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.

#94

So how did everything progress with this ? It would be a cool thing to know how to do.

#95

Much of it is posted here, but here is a basic over view of what I needed to do.

I loaded a image in to the backgroundImage property. For the target I created another BMP with a backGround color that was the same color as the backGroundColor property of the dotnet pictureBox controls, this is what is used as the transperent color.

To draw the target I’m using the GDI drawing methods that have been duscussed here to place the target BMP where the mouse is.

I have several event handlers for each of the joy stuck controls. The paint event that calls the drawing of the target function, mouseDown, mouseUp and mouseOut I think. I would have to have a look. With the way that I did it I now have the ability to multi select controls so that they can be reset and keyed through a RC menu as well as create groups of controls for saving poses just like PENAttribute Holder 2 but on streoids. For the pose capture I have a treeView and you can just scrub on the items in the tree and again I use GDI drawing, this time just using a filled rectangle as the slider. To show the selections of controls I use a system.drawing.pen and out line the control in yellow.

All in all it works well, it is a little slow to draw all the controls at once when scrubbing animation but it is acceptable. To get the controls to update durring scrubbing I’m using a timeChange callBack that gets the values from the parameters and applies them back to the poictureBox controls. I store an array of structs that hold the information about which parameters are to work with which pictureBox controls.

I can’t show the final results as the client will not allow it at this point. It is working very well and they love the tool and find it very easy to use. One cool feature that I added was being able to copy and paste values from one to the other with the ability to mirror the value on the X. I have other feature like being able to contrain the control to either X or Y depending on shift, ctrl alt being pressed and several other options. All the poses are store in an XML file on the server so that when some one saves a pose every one gets it.

#96

That sounds really cool Paul, and looks great too from the images you’ve posted…:applause: