John Labenski <jlaben...@gmail.com> wrote: (04/06/2009 05:00) >I ran the code and I see that the EVT_PAINT handler is incessantly >called when you scroll over and down a bit. I would guess that is >because you have overlapping windows which is not supported by >wxWidgets. Before you can make any headway you have to get it to stop >doing that. Put a print(os.date()) statement in the EVT_PAINT handler >to see what I mean. >
It's doing that because I asked it to with LAYER:Refresh() in OnMotion(), it has to redraw the visible parts of the track data. I can't do this in OnMotion directly because the track never becomes visible that way. While the OnPaint() function isn't used for the wxStaticBitmap because it's redrawn anyway, that redraw happens last, unless I do the track drawing in OnPaint() so it is the last thing drawn, thus remains visible. >I suggest trying to use a single wxWindow to do all the drawing and to >clip the bitmap and lines to only draw the visible portions. For the lines, I already do draw only the visible ones. On a large screen there are enough of them in a GPS track that I still had track flicker when I draw the chart myself, as redraw has to happen with every move of the chart. That's why I want the persistence effect that the wxStaticBitmap has in wxLua v2.8.7.0, as it means I see a steady image that only shows changes as lines are drawn on newly appearing areas. I'll look for a way to draw to one window, but even so, I still have to draw bits of bitmap every time to fill the newly appearing areas during moves, and avoid any draws on persitently appearing areas. I can't see how any way can work short of completely emulating what Google Maps does. As I appeared to have found a way to avoid that, I wanted to stay with it. It depended on overlapping wondows. Supported or not, it works without flicker, so long as we get to choose whether a wxStaticBitmap can have background erase events blocked or not. Right now the events changed between versions, and in neither state do we get control. >You can >even use a wxScrolledWindow if you like to make it more obvious to the >user that they can scroll around. > The wxScrolledWindow made a strange double-image based on some kind of instability or lag in translating co-ordinates read to co-ordinates printed. I abandoned it for a direct draw or move of an object because the problem was cured that way. Also I don't want scroll bars, I'll devise another method that takes a lot less screen space, or pops up on demand. As far as I could tell, wxScrolledWindow wouldn't scroll without them anyway. wxScrolledWindow is a general tool with built in methods that are ok for general use, but using it to solve what I wanted to do would come with baggage that didn't help (like that wretched MouseWheel problem :), by analogy it's like using MFC in Windows programming in cases where direct API access is better. If I can't find a way to do this that stays consistent through wxWidgets updates (looks increasingly unlikely), I'll learn to port it to C and do exactly that. wxWidgets might allow sptaial portability, but if temporal portability is impossible I'll choose staying with one platform and knowing the code will always run there. The Windows API has apparently been consistent enough in its core wince W95, so it's a safe bet. My first experiments with it suggest that the control it allows suits the way I like doing things anyway. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
