Forum > General

More Resize Questions on TBGRAGraphicCtrl

(1/3) > >>

SandyG:
Working on a a Gauge component  and started to try to optimize some of the redrawing. Got really far but ran into an issue where I can't find a property that will allow me to catch the Resize event property.

Resize seems to fire on any repaint of the component, not resize. Spent a while in the debugger and that's what it seems to do.

I'm trying to catch is when the component is resized either at design time or at run time.

The only way that I can find to see if the Width or Height has changed is looking at the previous saved values of Width or Height and comparing it to what it is in the Paint call. Works but sure seems like a hack to be able to invalidate a bunch of drawings that must be done. Basically I'm keeping the last state of Width and Height saved for later comparison in the Paint event to see if I need to invalidate everything.

Hope this make sense, what is the 'Right' or a 'Good' way to do this since Resize does not seem to work as needed.

This is on a component where  MyComponent <-TBGRAGraphicCtrl <-TGraphicControl this is the hierarchy  (Basically the BGRAThemedGauge)

Sandy

jamie:
by your description you may be suffering from flickering?

when changing a size of some child control it most likely propagates down though the stack of resizes.

Since a TGraphicControl is pure graphics sitting on top of a needed Windows Parent control, sizing the window control will also
go down through the list to ensure the child controls get fully drawn.

  You can try blocking the WM_EraseBkGnd message.


 

SandyG:
Not an issue of flickering more trying to know if a resize happens so I can know to reset a 'dirty' flag in each of the graphic elements that builds the component.

The component is an analog gauge, it has a border, face, scale, and a pointer. Each has a bitmap generated only when first painted or something changes.

For example if the color of the scale is changed, the scale object is marked as 'dirty" and recreated. Same for each visual component of the Gauge. Increases performance significantly only regenerating a specific part of the gauge. This works really well. 3 to 4 times speed as only really the pointer changes frequently, the rest of the gauge elements are effectively cached unless something specifically changes in any of the parts.

The problem now is design time. If the size of the component is changed, how do you catch that event to force all parts of the Gauge to be dirty so the resize happens with a regenertion of all parts?

At run time it's less of a problem  as I think I could overload Width and Height and mark everything as 'dirty'. But not while in design mode. I do need to check if I can override Width and Height and possibly the designer calls these properties, more testing needed...

Hope this makes sense.

This might be better moved to LCL section, I posted in general by mistake.

Sandy

jamie:
Normally you insert code in your control that monitors the editing session of being in the IDE so the code does not get executed.

IN any case, if you use the WM_WindowChangingPOS message, you can inspect the new values and reset them before they get applied.

The WM_WindowChangedPos is after the fact .

SandyG:
Watching windows message could work, only need to do resize, but could just be fine. Odd no existing event can catch the resize properly. After the WM_WindowChangedPos happens may work work if it seen before a paint message happens, otherwise won't work. You mentioned it's after the fact which I assume may be the paint.

Will have to create a listener for the WM_WindowChangedPos, I'll guess it's as easy as pie in LCL 😉

Thanks for your help, trying to get all the code working so I can clean it all up and commit it!

Sandy

Navigation

[0] Message Index

[#] Next page

Go to full version