temporarily prevent any gadget painting?
BlitzMax Forums/MaxGUI Module/temporarily prevent any gadget painting?
| ||
| Hey, Does anyone know of any way you can prevent a gadget from repainting? I am building a property grid and I would like to build the grid out of gadgets and then redraw in one hit. Any ideas ? |
| ||
| Once created the OS should take care about all redraws, not sure if you could prevent that. Most of the time we want the opposite, an extra redraw to update an progress bar during long operations for example, and we have to give the OS extra time to do it. May try to kill all events during creation with a hook. How is the property grid made, that the redraw does interfere that much? Most of the time it is enough to build the gadgets hidden and just show them afterwards, thus the flickering during build is not visible. |
| ||
| It is possible to block the repaint message on non-canvas gadgets via a hook? The property grid is made up of panels and gadgets. There seems to be a noticable delay when the grid is being created. The grid is recreated very time a node in the application is selected (as each node has different attributes) so the issue is for example if you are clicking to move a node in the editor.. you get a lag in the editor as the app recreates the property grid. the property grid is created as a new object and upon completion it replaces the old proeprty grid, so flicker does not occur, it is just the lag of creation/intital-paints I am trying to bypass. It might not be because of repaints, but before I dive into finding a solution I wanted to see if anyone had any info. Last edited 2011 Last edited 2011 |
| ||
| It is possible to block the repaint message on non-canvas gadgets via a hook? Yes and no. The paint during creation is something which probably can't be blocked, but I have the feeling (wild guess) that is not the problem in your case. When the property grid is done gadget by gadget I could imagine that every new gadget has to fit itself into the place it should go and the GadgetLayout keeps the other gadgets busy, because in the grid they depend on each other (dynamic) and this increases with every new gadget. Nevertheless I never faced that problem and it is just a try. It might not be because of repaints... Maybe. How many gadgets do you created in one go? |
| ||
| Maybe place everything on a master panel which is hidden and then show it? Last edited 2011 |
| ||
| Maybe. How many gadgets do you created in one go? It depeneds on the selected object, but to answer id say anywhere from 10 to 100 max (depending on the complexity of the objects attributes) Maybe place everything on a master panel which is hidden and then show it? It is currntly doing this, creates a new property grid then swaps it with the old one after its finished. I'll have to do some more digging, both your comments have made me think a bit. Once I have a chance to dig and optimize i'll post back here with my findings. Thanks so far :) |
| ||
| Well I didn't really update this thread as I decided that there was probably not much I could do about the "minor" delay in drawing. Fast forward a month and well... http://www.blitzbasic.com/Community/posts.php?topic=96203 For anyone elses future reference these two very basic win32 functions are good for disabling redraw on windows gadgets. There is no support for osx yet, it would probably involve a tweak to maxgui and do some subclassing or something to override the drawRect methods... Last edited 2011 |
   |