wxlua-users Mailing List for wxLua

Hello!
I found out how to do it, even wxImage was a bit tricky (wxInputStream is 
not an overloaded ctor, but a parameter to LoadFile() :)). So, it works 
well now, but I can't use my xrc file. It's in the zip, and the main 
window works (wxFrame), but the other windows not (the xrc file contains 
other 5-6 dialog). When the program reaches the line like this:
if xmlResource:LoadDialog(m_about,wx.NULL,"ID_DLG_ABOUT") then
It fails, and I got a messagebox with: 'Unhandled exception'. If I remove 
the wx.wxFileSystem().AddHandler(wx.wxArchiveFSHandler) and I load the 
dialog from a simple xrc file, it works as it should. Any idea, how can I 
fix this? I don't want to separate the xrc files for every dialog...
Thanks: Attila

On Fri, Jun 26, 2009 at 12:54 PM, Attila<ejj...@gm...> wrote:
> Hello!
> I find a very good feature in DialogBlocks - adding xrc resource as a
> zipped file name myproject.xrs, then I can load the myproject.xrc from it,
> after I did the needed wxFileSystem call. But I want to add my images in
> this way too, because compressed resource uses less hard-disk space.
> DialogBlocks added it to the xrs file, but I am unable to load it.
> wxXmlResource:LoadBitmap() doesn't work, if I use the filename as it's
> parameter. I checked the wx source, and I see it does something with
> nodes, so I assume it excepts the image inside the xrc file.
I haven't used XRC to do much of anything, but I see that you can put
bitmaps into some sort of zip file that the xrc file can load. Maybe
you can google a bit and find some examples, even wxPython examples
should be easy enough to translate to wxLua.
http://docs.wxwidgets.org/trunk/overview_xrc.html#overview_xrc_binaryresourcefiles
http://books.google.com/books?id=CyMsvtgnq0QC&pg=PA409&lpg=PA409&dq=wxwidgets+xrc+wxbitmap+zip&source=bl&ots=SS8zi6DoDf&sig=SOweAv8Ymh27K8eGutWnQEtD7jM&hl=en&ei=K_xHSrqiO-Cxtwek3vjmBg&sa=X&oi=book_result&ct=result&resnum=3
> DialogBlocks
> also writes C++ file for the xrc, I checked that, it writes something like
> this:
>
> myApp::GetBitmapResource(wxString &name)
> {
>  wxUnusedVar name;
>  return wxNullBitmap;
> }
>
> Sorry if the code isn't 100% correct, I am not a C++ programmer, and the
> code isn't ahead me :) So, it returns with a nullbitmap... What should I
> do? Can I add the image into the xrc file? Or can I get them from the xrs
> file? Thanks for the replyes.
I have no idea what this code is all about, it doesn't make sense to
always return an invalid wxBitmap? Some sort of dummy code that
DialogBocks expects you to fill out?
Regards,
 John

On Sun, Jun 28, 2009 at 5:55 AM, Attila<ejj...@gm...> wrote:
> Hello!
> I have a problem with the checkboxes. I am using
> wx.wxEVT_COMMAND_CHECKBOX_CLICKED event handler, to disable some other
> control. It works fine, when I click on the control. But I set the
> checkbox values by wxCheckBox:SetValue(true/false). This doesn't call the
> event, so I tried with
wxWidgets controls normally do not sent event for programmed changed,
only from user interaction. I often make a separate function to handle
changes so that I can call it both from the event handler or after
I've changed the value programmatically.
>myApp:ProcessEvent(wx.wxCommandEvent(wx.wxEVT_COMMAND_CHECKBOX_CLICKED,xmlResource:GetXRCID(checkbox)))
> which calls the event, but there I use 'if event:IsChecked() then'
> conditions, which is always false, because the event is 'fake', not a real
> click. Can I set up the IsChecked field of the event,
local e = wx.wxCommandEvent(wx.wxEVT_COMMAND_CHECKBOX_CLICKED,xmlResource:GetXRCID(checkbox))
e:SetInt(1)
myApp:ProcessEvent(e)
Note: IsChecked() returns GetInt() != 0
> or is there any call which generates an event too?
No.
Regards,
 John

Hello!
I have a problem with the checkboxes. I am using 
wx.wxEVT_COMMAND_CHECKBOX_CLICKED event handler, to disable some other 
control. It works fine, when I click on the control. But I set the 
checkbox values by wxCheckBox:SetValue(true/false). This doesn't call the 
event, so I tried with 
myApp:ProcessEvent(wx.wxCommandEvent(wx.wxEVT_COMMAND_CHECKBOX_CLICKED,xmlResource:GetXRCID(checkbox))) 
which calls the event, but there I use 'if event:IsChecked() then' 
conditions, which is always false, because the event is 'fake', not a real 
click. Can I set up the IsChecked field of the event, or is there any call 
which generates an event too?
Thanks for the replies: Attila

Hello!
I find a very good feature in DialogBlocks - adding xrc resource as a 
zipped file name myproject.xrs, then I can load the myproject.xrc from it, 
after I did the needed wxFileSystem call. But I want to add my images in 
this way too, because compressed resource uses less hard-disk space. 
DialogBlocks added it to the xrs file, but I am unable to load it. 
wxXmlResource:LoadBitmap() doesn't work, if I use the filename as it's 
parameter. I checked the wx source, and I see it does something with 
nodes, so I assume it excepts the image inside the xrc file. DialogBlocks 
also writes C++ file for the xrc, I checked that, it writes something like 
this:
myApp::GetBitmapResource(wxString &name)
{
 wxUnusedVar name;
 return wxNullBitmap;
}
Sorry if the code isn't 100% correct, I am not a C++ programmer, and the 
code isn't ahead me :) So, it returns with a nullbitmap... What should I 
do? Can I add the image into the xrc file? Or can I get them from the xrs 
file? Thanks for the replyes.
Regards: Attila

Thanks, it works. Doesn't make sense entirely, though. If it does autoresize, it doesn't fit anyway. Even if it does, explicitly telling it not to wrap (or as in my latest case as quoted below, to wrap with a wide setting that won't alter the smaller text display) should override automatic behaviour. If it doesn't, there seems to be no point to the wxStaticText:Wrap() setting.
John Labenski <jla...@gm...> wrote:
(22/06/2009 23:40)
>
>Use the wx.wxST_NO_AUTORESIZE window style to not have it resize.
>
>See the comment for the style here:
>http://docs.wxwidgets.org/stable/wx_wxstatictext.html
>
>Regards,
> John
>
>On Mon, Jun 22, 2009 at 5:16 PM,
>lostgallifreyan<los...@gm...> wrote:
>> LABEL=
>> "LINE_01:\txx = x1;\n"
>> .."LINE_02:\tyy = y1*Cos(XTheta) + z1*Sin(XTheta);\n"
>> .."LINE_03:\tzz = z1*Cos(XTheta) - y1*Sin(XTheta);\n"
>> .."LINE_04:\ty1 = yy;\n"
>> .."LINE_05:\tx1 = xx*Cos(YTheta) - zz*Sin(YTheta);\n"
>> .."LINE_06:\tz1 = xx*Sin(YTheta) + zz*Cos(YTheta);\n"
>> .."LINE_07:\tzz = z1;\n"
>> .."LINE_08:\txx = x1*Cos(ZTheta) - y1*Sin(ZTheta);\n"
>> .."LINE_09:\tyy = x1*Sin(ZTheta) + y1*Cos(ZTheta);\n"
>>
>> STAT=wx.wxDialog(wx.NULL,-1,"Stuff",wx.wxPoint(-1,-1),wx.wxSize(800,800))
>> XXXX=wx.wxPanel(STAT,-1) XXXX:SetSize(1200,1200)
>> TEXT=wx.wxStaticText(XXXX,-1,"",wx.wxPoint(-1,-1),wx.wxSize(900,900)) TEXT:Wrap(1000)
>> TEXT:SetLabel(LABEL) STAT:Show()
>>
>>
>>
>>
>> I deliberately and explicitly set huge sizes to be sure that no wrap is forced on the label text, but still it ALWAYS wraps lines and fails to show text beyond the first few lines. Why?
>>
>> (Note that I have no intention of using such silly sizes as those for a small modeless dialog, I'm just doing it to make the point that some hidden nonsense is restricting what should not be restricted!)
>>
>>
>> ------------------------------------------------------------------------------
>> Are you an open source citizen? Join us for the Open Source Bridge conference!
>> Portland, OR, June 17-19. Two days of sessions, one day of unconference: 250ドル.
>> Need another reason to go? 24-hour hacker lounge. Register today!
>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>> _______________________________________________
>> wxlua-users mailing list
>> wxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>>
>
>------------------------------------------------------------------------------
>Are you an open source citizen? Join us for the Open Source Bridge conference!
>Portland, OR, June 17-19. Two days of sessions, one day of unconference: 250ドル.
>Need another reason to go? 24-hour hacker lounge. Register today!
>http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>_______________________________________________
>wxlua-users mailing list
>wxl...@li...
>https://lists.sourceforge.net/lists/listinfo/wxlua-users

Use the wx.wxST_NO_AUTORESIZE window style to not have it resize.
See the comment for the style here:
http://docs.wxwidgets.org/stable/wx_wxstatictext.html
Regards,
 John
On Mon, Jun 22, 2009 at 5:16 PM,
lostgallifreyan<los...@gm...> wrote:
> LABEL=
> "LINE_01:\txx = x1;\n"
> .."LINE_02:\tyy = y1*Cos(XTheta) + z1*Sin(XTheta);\n"
> .."LINE_03:\tzz = z1*Cos(XTheta) - y1*Sin(XTheta);\n"
> .."LINE_04:\ty1 = yy;\n"
> .."LINE_05:\tx1 = xx*Cos(YTheta) - zz*Sin(YTheta);\n"
> .."LINE_06:\tz1 = xx*Sin(YTheta) + zz*Cos(YTheta);\n"
> .."LINE_07:\tzz = z1;\n"
> .."LINE_08:\txx = x1*Cos(ZTheta) - y1*Sin(ZTheta);\n"
> .."LINE_09:\tyy = x1*Sin(ZTheta) + y1*Cos(ZTheta);\n"
>
> STAT=wx.wxDialog(wx.NULL,-1,"Stuff",wx.wxPoint(-1,-1),wx.wxSize(800,800))
> XXXX=wx.wxPanel(STAT,-1) XXXX:SetSize(1200,1200)
> TEXT=wx.wxStaticText(XXXX,-1,"",wx.wxPoint(-1,-1),wx.wxSize(900,900)) TEXT:Wrap(1000)
> TEXT:SetLabel(LABEL) STAT:Show()
>
>
>
>
> I deliberately and explicitly set huge sizes to be sure that no wrap is forced on the label text, but still it ALWAYS wraps lines and fails to show text beyond the first few lines. Why?
>
> (Note that I have no intention of using such silly sizes as those for a small modeless dialog, I'm just doing it to make the point that some hidden nonsense is restricting what should not be restricted!)
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: 250ドル.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

LABEL=
"LINE_01:\txx = x1;\n"
.."LINE_02:\tyy = y1*Cos(XTheta) + z1*Sin(XTheta);\n"
.."LINE_03:\tzz = z1*Cos(XTheta) - y1*Sin(XTheta);\n"
.."LINE_04:\ty1 = yy;\n"
.."LINE_05:\tx1 = xx*Cos(YTheta) - zz*Sin(YTheta);\n"
.."LINE_06:\tz1 = xx*Sin(YTheta) + zz*Cos(YTheta);\n"
.."LINE_07:\tzz = z1;\n"
.."LINE_08:\txx = x1*Cos(ZTheta) - y1*Sin(ZTheta);\n"
.."LINE_09:\tyy = x1*Sin(ZTheta) + y1*Cos(ZTheta);\n"
STAT=wx.wxDialog(wx.NULL,-1,"Stuff",wx.wxPoint(-1,-1),wx.wxSize(800,800))
XXXX=wx.wxPanel(STAT,-1) XXXX:SetSize(1200,1200)
TEXT=wx.wxStaticText(XXXX,-1,"",wx.wxPoint(-1,-1),wx.wxSize(900,900)) TEXT:Wrap(1000)
TEXT:SetLabel(LABEL) STAT:Show()
I deliberately and explicitly set huge sizes to be sure that no wrap is forced on the label text, but still it ALWAYS wraps lines and fails to show text beyond the first few lines. Why?
(Note that I have no intention of using such silly sizes as those for a small modeless dialog, I'm just doing it to make the point that some hidden nonsense is restricting what should not be restricted!)

On Thu, Jun 11, 2009 at 6:24 PM, Duncan Cross<dun...@gm...> wrote:
> Hi List,
>
> I'm trying to get my wxSTC to show Unicode characters in a UTF-8
> document, and from reading around it looked like the way to do this is
> to call (where "stc" is the control itself):
>
>  stc.CodePage = wxstc.wxSTC_CP_UTF8;
>
> ...but while this initially seemed to have no effect, I realised that
> it had - even though it's still showing several garbage characters
> instead of a single Unicode one, if I move the cursor with the cursor
> keys, it treats each multi-byte sequence as a unit. It just isn't
> rendering properly.Does anyone have an example of a wxStyledCtrl
> successfully using UTF-8 characters with wxLua?
Sorry, I don't have any experience with this, but you can at least see
if scite, the editor that the authors of Scintilla wrote, can handle
it.
Regards,
 John

Hi List,
I'm trying to get my wxSTC to show Unicode characters in a UTF-8
document, and from reading around it looked like the way to do this is
to call (where "stc" is the control itself):
 stc.CodePage = wxstc.wxSTC_CP_UTF8;
 ...but while this initially seemed to have no effect, I realised that
it had - even though it's still showing several garbage characters
instead of a single Unicode one, if I move the cursor with the cursor
keys, it treats each multi-byte sequence as a unit. It just isn't
rendering properly.Does anyone have an example of a wxStyledCtrl
successfully using UTF-8 characters with wxLua?
Thank you,
-Duncan

Solved this too:
FRAME:Connect(wx.wxEVT_DROP_FILES,function(E) FRAME:Raise() FRAME:Update() TrackLoad(E:GetFiles()[1]) E:Skip() end)
Not sure why I didn't think earlier of putting Raise() in the drag/drop handler before the main payload, but I have now, and it works well, though I have to force the update too, or it doesn't get repainted till the payload is done.

I solved it. It IS possible to emulate that desirable behaviour of the wxStaticBitmap. :) If you paint to the same place every time, the pixels are not repainted unless they need to be. So I can make a huge bitmap sized panel as child to the client-area-sized panel, and use Move() on the big one, just as I did with the bitmap.
I tried using GetSubBitmap as an experiment and it failed as before. While the peices CAN be snagged and drawn as fast as scrolling a large single one, this is only true in Windows 98 (and presumably any system) if there is enough memory. It really doesn't matter how many fragments I cut and collage together, if the total client size to be drawn is big enough that fast redraws threaten to use something up. Even if I delete each bitmap fragment and wxRect or whatever as I go along, it stutters and freezes within moments after a fast start. And anyway, you MUST have one big bitmap to start with, to get sub bitmaps from, so if the system isn't loading that it's game over anyway, so loading one big one is best, just do it sparingly and make manipulations as few, simple and direct as possible.
Regarding layers, I've managed to reduce to two, the input control layer and the vector draw layer are the same, over a chart layer. While that has two panels they are parent and child, only two panels have the same parent (the frame) and overlap in equal size and position. I don't know what this means, 'overlapping windows not supported'. From what I've seen the behaviour is constent and has been for all the versions of wxLua I've tried, I think. Considering it works to solve significant drawing problems, maybe it should be supported! Something that useful ought to be explored, exploited, and guarded against future changes breaking it. John, what platform do you use? I guess when you ran my examples and saw them work, at least as described, it suggests it's not only workable on W9X. And if you're using Linux it surely implies it's based on something deep and determined in wxWidgets or wxLua, whether nominally supported or not.
I still use that OnPaint function to do the vector drawing. (Clipped to only visible area, as I thought was already clear). I know you said I ought to stop it from calling OnPaint every time the chart was moved around, but I don't agree, it's crucial to the way it works that it is done this way. And it DOES work, cleanly, in more than one version now that I emulated that wxStaticBitmap behaviour from the earlier version. I think the more basic the methods I use, the less likely it is to suffer borkage with further changes too.
Lastly, I stress again that the wxScrolledWindow really didn't work well. It was a good example of how using elaborate self-contained tools with parts I can't control is a good way to always be fighting with the system instead of using it. Jittering images during mouse-grab scrolling and weird unstoppable mousewheel events were just a part of that one, if I'd stayed with it I might have found more instead of discovering far more useful ways to use basic controls and methods common to most wxWindows. I have more freedom this way, and likely more security against changes too. Now, if I could build my own SpinControls... :) But that might be overplaying the hand.
>
>On Mon, Jun 1, 2009 at 6:11 PM, lostgallifreyan
><los...@gm...> wrote:
>>
>> I know, that's why I just sent the post I sent just before I found this one of yours. It contains full context so no further circles of guessing are needed. It's taking too much time to reduce to contextless samples so this is as good as I can get it. I need to know if it's only working because of some bug that happens to favour it, or if there's a proper way to get the same results.
>>
>
>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.
>
>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. You can
>even use a wxScrolledWindow if you like to make it more obvious to the
>user that they can scroll around.
>
>Regards,
> John
>
>------------------------------------------------------------------------------
>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
>wxl...@li...
>https://lists.sourceforge.net/lists/listinfo/wxlua-users

John Labenski <jla...@gm...> 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.

On Mon, Jun 1, 2009 at 6:11 PM, lostgallifreyan
<los...@gm...> wrote:
>
> I know, that's why I just sent the post I sent just before I found this one of yours. It contains full context so no further circles of guessing are needed. It's taking too much time to reduce to contextless samples so this is as good as I can get it. I need to know if it's only working because of some bug that happens to favour it, or if there's a proper way to get the same results.
>
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.
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. You can
even use a wxScrolledWindow if you like to make it more obvious to the
user that they can scroll around.
Regards,
 John

John Labenski <jla...@gm...> wrote:
(01/06/2009 23:03)
>Please don't send 2.5 Mb messages to the list. There has to be a
>easier way to make it clear what your issues are.
>
There is. I cancelled that post and sent a variant just now that draws the 'chart' panel as a simple rectangle to avoid big files.
>First, wxWidgets does not officially support z-ordering of overlapping
>windows. If it works great, if things don't, you know why.
>
Ok.
>Secondly, I don't really have time to try to decipher your code, I
>barely have enough time for wxLua.
I know, that's why I just sent the post I sent just before I found this one of yours. It contains full context so no further circles of guessing are needed. It's taking too much time to reduce to contextless samples so this is as good as I can get it. I need to know if it's only working because of some bug that happens to favour it, or if there's a proper way to get the same results.

On Mon, Jun 1, 2009 at 10:45 AM, lostgallifreyan
<los...@gm...> wrote:
>
>
> Thanks, that one's nice, no flicker of any kind. I'm having trouble integrating it into my main script but I'll post once I sort out the confusion. I guess there's no problem with two OnPaint() functions? So long as their names are different, one for the PANEL painting, one for the layer vector stuff..
>
Please don't send 2.5 Mb messages to the list. There has to be a
easier way to make it clear what your issues are.
First, wxWidgets does not officially support z-ordering of overlapping
windows. If it works great, if things don't, you know why.
Secondly, I don't really have time to try to decipher your code, I
barely have enough time for wxLua. What exactly is wrong? The method I
showed to draw your bitmap using the EVT_PAINT handler was flicker
free. Is that not what you want? I can also suggest trying to draw
your bitmap in the wxEVT_ERASE_BACKGROUND handler. Also, try calling
Refresh(false) to not clear the window first.
Hope this helps,
 John

John Labenski <jla...@gm...> wrote:
(01/06/2009 04:30)
>>>> Another thing I have found is a failure in EVT_ERASE_BACKGROUND blocking. I'm getting
>>>> flicker in something that didn't flicker in the previous release of wxLua. Note the two commented lines...
>>>
>
>Yes the static bitmap flickers. Why don't you draw it yourself...
Ok, I tried it, and it doesn't work in context, and I think it's similar to what I already tried, though the GetEventObject():DynamicCast("wxWindow") bit looks useful, and new to me. (I'd earlier just specified which panel I wanted to use directly).
There's a limit to how much I can minimise to a sample without defeating realism, so I've done the only thing that makes sense to me now. I've prepared and tested the smallest full-context sample I can, it includes a file of GPS data thinned in density and reduced to pixel co-ordinates only. The script is also in the attached ZIP file to protect it from word wrap borkage, but here it is for those who don't (or can't) see the attached file, after a few notes on what you should see if you run this.
First, it draws the 'chart' as a simple rectangle on one panel, then draws the track data on another panel, and uses a third panel to take control input to drag the image around the viewable area. This third panel is there to avoid message and calculation conflicts with stuff on the image panels. Omitting it has several times been more trouble than its worth so it stays. When the chart is moved by dragging on the input panel, the track in the visible area only is redrawn on the layer panel to make the process acceptably fast, and to avoid flicker of the visible track section(s) the wxStaticBitmap was used because it does not need OnPaint() redrawing, so it persists if nothing is drawn over it, and only the newly appearing parts flicker as they are drawn in while dragging. Nothing I've tried has come close to looking as good as this scheme does in wxLua v2.8.7.0 and if the wxStaticBitmap allowed me to block background erasing, it would work just as well in v2.8.10.0. Whatever I do, it has to work and look like it does now, or better if possible. :)
I made the 'Chart' from a simple drawn bitmap to avoid sending a couple of MB in GIF image. Also, I'm aware of DrawLines() as opposed to DrawLine() but my code uses a gradient table to show speeds as a graphic device, so even though the DrawLines() function is likely faster, I can't use it, as it would all be one colour, so I kept the sample faithful to the method I must use.
The script:
function Main()
 FRAME=wx.wxFrame(wx.NULL,-1,"") FRAME:CreateStatusBar() TITLE="GPS Chart" FRAME:SetTitle(TITLE)
 INPUT=wx.wxPanel(FRAME,-1) PANEL=wx.wxPanel(FRAME,-1) LAYER=wx.wxPanel(FRAME,-1) CHART=wx.wxStaticBitmap(PANEL,-1)
 FRAME:Connect(wx.wxEVT_SIZE,OnSize)
 INPUT:Connect(wx.wxEVT_LEFT_DOWN,OnLeftDown)
 INPUT:Connect(wx.wxEVT_MOTION,OnMotion)
 INPUT:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end)
 LAYER:Connect(wx.wxEVT_PAINT,OnPaint)
 LAYER:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end)
 BITMAP=wx.wxBitmap("Ashton Court.gif",wx.wxBITMAP_TYPE_GIF)
 CHART:SetSize(BITMAP:GetWidth(),BITMAP:GetHeight()) CHART:SetBitmap(BITMAP)
 OX,OY,PX,PY=0,0,0,0 --O=Offset, P=Pixel
 T1=TextLine(DataLoad("SAMPLE.log"),{})
 T2,T3={},{}
 for N in ipairs(T1) do
 _,_,T2[N],T3[N]=string.find(T1[N],"^(.-)\t(.-)$") T2[N],T3[N]=T2[N]+0,T3[N]+0
 end
 T2[0],T3[0],T2[#T2+1],T3[#T3+1]=T2[1],T3[1],T2[#T2],T3[#T3]
 FRAME:SetSize(800,600) FRAME:Centre() FRAME:Show()
end
--==================== Event Handling ====================--
function OnSize(E)
 CX,CY=FRAME:GetClientSizeWH() INPUT:SetClientSize(CX,CY) LAYER:SetClientSize(CX,CY) PANEL:SetClientSize(CX,CY)
 DX,DY=CX-BITMAP:GetWidth(),CY-BITMAP:GetHeight()
 if OX<DX then OX=DX end if OY<DY then OY=DY end CHART:Move(OX,OY) LAYER:Refresh()
end
function OnLeftDown(E)
 PX,PY=OX-E:GetX(),OY-E:GetY() E:Skip()
end
function OnMotion(E)
 if E:LeftIsDown() then
 OX,OY=PX+E:GetX(),PY+E:GetY()
 if OX>0 then OX=0 end if OY>0 then OY=0 end if OX<DX then OX=DX end if OY<DY then OY=DY end
 CHART:Move(OX,OY) LAYER:Refresh()
 end E:Skip()
end
function OnPaint(E)
 local DC,P=wx.wxPaintDC(LAYER),wx.wxPen()
 for N in ipairs(T1) do
 if (T2[N]>-OX and T3[N]>-OY and T2[N]<CX-OX and T3[N]<CY-OY) then
 P:SetColour(0,0,0) P:SetWidth(3) DC:SetPen(P) DC:DrawLine(T2[N]+OX,T3[N]+OY,T2[N+1]+OX-1,T3[N+1]+OY-1)
 P:SetColour(255,0,0) P:SetWidth(2) DC:SetPen(P) DC:DrawLine(T2[N-1]+OX,T3[N-1]+OY,T2[N]+OX,T3[N]+OY)
 end
 end
 DC:delete() P:delete() E:Skip()
end
--=================== Common Functions ===================--
function DataLoad(F)
 F=assert(io.open(F,"rb")) local D=F:read("*a")
 F:close() return D
end
function TextLine(S,T) --String, Table.
 S=string.gsub(S,"\r\n?","\n")
 if (string.sub(S,-1)~="\n") then S=S.."\n" end
 for X in string.gfind(S,"(.-)\n") do table.insert(T,X) end
 return T
end
--====================================================================================================================--
Main()

On Mon, Jun 1, 2009 at 10:45 AM, lostgallifreyan
<los...@gm...> wrote:
>
> Didn't work, but a clue was a lack of quotes round the filepath after the -c switch in the DisplayOutput window. So I went to frame:Connect(ID_RUN... and changed a line as follows:
>      local cmd = '"'..programName..'" '..console..openDocuments[id].filePath
> to
>      local cmd = '"'..programName..'" '..console.."\""..openDocuments[id].filePath.."\""
> which works.
Thanks, fixed in CVS.
Regards,
 John

On Mon, Jun 1, 2009 at 11:47 AM, John Labenski <jla...@gm...> wrote:
> Sourceforge has crippled their shell and we are no longer able to
> provide daily snapshots. I will remove the link to them.
Too bad.
> You can use ssh on port 22 to get the CVS files by exporting
> CVS_RSH=/bin/ssh.exe .
>
> $cvs -z3 -d:ext:You...@wx...:/cvsroot/wxlua
> co -P wxLua
>
Great, I will try that. Thanks.
-- 
Regards,
Ryan

On Mon, Jun 1, 2009 at 10:07 AM, Ryan Pusztai <rpu...@gm...> wrote:
> Hi,
> Are the nightly builds working. When I click on the link from the main site
> download page it gives an error. I am behind a firewall so I can't use CVS
> so I wanted the latest version of the code. Thanks
Sourceforge has crippled their shell and we are no longer able to
provide daily snapshots. I will remove the link to them.
You can use ssh on port 22 to get the CVS files by exporting
CVS_RSH=/bin/ssh.exe .
$cvs -z3 -d:ext:You...@wx...:/cvsroot/wxlua
co -P wxLua
Regards,
 John

John Labenski <jla...@gm...> wrote:
(01/06/2009 04:30)
>
>On Sat, May 30, 2009 at 8:19 AM, lostgallifreyan
><los...@gm...> wrote:
>>
>> I thought wxLua was a C-coded binary. But I did notice that the Lua script produced what appeared to be the same thing. I think you mentioned this a month or so back, but I still manage to get confused by this. How much of the wxLua editor is actually Lua?
>
>All of it, except for command line processing.
>
Ok. Duplicating exact function then? Meaning the EXE has all that the Lua script has, plus commandline processing? I ask because the EXE works as usual if I hide the script from it, suggesting it's not using it, at least not as I usually call it.
>>>>That fails too because it doesn't recognise spaces in file names! This is definitely not
>>>> an improvement. While the script does open in wxLua, it won't run because even though
>>>> it has it opened, it can't actually FIND it by file name to run it.
>>>
>>>Really? I have no problems opening files with spaces in its name.
>>>Please give more details.
>>
>> Not much I can add, but there is some...
>> I open the file "GPS Chart/lua" by manually browsing from the v2.10 wxLua, then try to run it from the Debug menu. A "wxLua Console" window pops up saying:
>> Lua: Error occurred while opening file
>> cannot open C:\WINDOWS\Desktop\GPS: No such file or directory
>>
>
>It is probably failing in the function "OpenFile(event)" or io.open()
>in LoadFile() in editor.wx.lua. As you can see, there's no special
>filename processing going on. Can you open the file if you hardcode
>the path for io.open() in LoadFile()?
>
Didn't work, but a clue was a lack of quotes round the filepath after the -c switch in the DisplayOutput window. So I went to frame:Connect(ID_RUN... and changed a line as follows:
 local cmd = '"'..programName..'" '..console..openDocuments[id].filePath
to
 local cmd = '"'..programName..'" '..console.."\""..openDocuments[id].filePath.."\""
which works.
The wxLua console window pops up but is empty, and the script loads and the frame shows. Those quotes are vital when the file path is passed to os.execute(), at least in MSW they are...
>>>
>>>> Another thing I have found is a failure in EVT_ERASE_BACKGROUND blocking. I'm getting
>>>> flicker in something that didn't flicker in the previous release of wxLua. Note the two commented lines...
>>>
>
>Yes the static bitmap flickers. Why don't you draw it yourself like this?
>
>function Main()
> FRAME=wx.wxFrame(wx.NULL,-1,"")
> FRAME:CreateStatusBar() FRAME:SetStatusText(" ")
> LAYER=wx.wxPanel(FRAME,-1) PANEL=wx.wxPanel(FRAME,-1)
>--CHART=wx.wxStaticBitmap(PANEL,-1)
> FRAME:SetSize(800,600) FRAME:Centre()
>
> BITMAP=wx.wxBitmap("image.jpg")
> BX,BY,OX,OY,PX,PY=BITMAP:GetWidth(),BITMAP:GetHeight(),0,0,0,0
>--CHART:SetBitmap(BITMAP)
>
> FRAME:Connect(wx.wxEVT_SIZE,OnSize)
> LAYER:Connect(wx.wxEVT_LEFT_DOWN,function(E) PX,PY=OX-E:GetX(),OY-E:GetY() end)
> LAYER:Connect(wx.wxEVT_MOTION,OnMotion)
> LAYER:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end)
> PANEL:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end) --Either of these ought to stop flicker but don't.
> --CHART:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end) --Neither of them are needed in earlier wxLua anyway.
>
> PANEL:Connect(wx.wxEVT_PAINT,OnPaint)
>
> FRAME:Show(true)
>end
>
>function OnPaint(E)
> local pdc = wx.wxPaintDC(E:GetEventObject():DynamicCast("wxWindow"))
> pdc:DrawBitmap(BITMAP, OX, OY, false)
> pdc:delete()
>end
>
>function OnSize(E)
> CX,CY=FRAME:GetClientSizeWH() PANEL:SetClientSize(CX,CY)
>LAYER:SetClientSize(CX,CY) CX,CY=CX-BX,CY-BY
> if OX<CX then OX=CX end if OY<CY then OY=CY end LAYER:Refresh()
> PANEL:Refresh()
>end
>
>function OnMotion(E)
> if E:LeftIsDown() then
> OX,OY=PX+E:GetX(),PY+E:GetY()
> if OX>0 then OX=0 end if OY>0 then OY=0 end if OX<CX then OX=CX end if OY<CY then OY=CY end
> --CHART:Move(OX,OY)
> PANEL:Refresh()
> end
>end
>
>Main()
>
Thanks, that one's nice, no flicker of any kind. I'm having trouble integrating it into my main script but I'll post once I sort out the confusion. I guess there's no problem with two OnPaint() functions? So long as their names are different, one for the PANEL painting, one for the layer vector stuff..

Hi,
Are the nightly builds working. When I click on the link from the main site
download page it gives an error. I am behind a firewall so I can't use CVS
so I wanted the latest version of the code. Thanks
-
Regards,
Ryan

John Labenski <jla...@gm...> wrote:
(01/06/2009 04:01)
>I don't really understand what you're trying to do. You first said
>that Raise() works, but you couldn't make it active since there is no
>function for this. I checked and I didn't see one either. Are you
>really sure that that your UI can only work if you bring your app to
>the foreground and make it active when the mouse go into the window?
>What's wrong with the user dragging stuff onto the app and then
>clicking the app the raise and focus it?
>
As far as I know, Raise() just changes a place in a sequence of numbers, some kind of refresh or redraw has to happen to redaw all windows in the system if they have to appear on top of any others. I tried following Raise() with FRAME:Update() and FRAME:Refresh() both singly and together though, and nothing happened.
What I want to do is drag a file to the window so it gets loaded, replacing the previously displayed track data on the chart. That way I can see some line and if I want to see how a different track across the same space differs I can watch the change as the new replaces the old. This needs the Raise() to work the instant the file is dropped, at the latest, ideally the moment the draged file pointer arrives in the window. Lower() works fine to make the window drop visibly to the back the instant the file is dropped, I just want Raise() to work likewise to bring it to the front.
Maybe the problem is NOT in Raise(). I read yesterday that it has more than it's fair share of problematic history, but maybe in this case the Z-order assignment is fine, but the window just isn't getting redrawn unless it had focus even while it was inactive, so all other windows, being redrawn, will appear over it if their precendence is higher in Z-order that the wxLua frame's previous place in that order.
But having tried FRAME:Update() and FRAME:Refresh() and SetFocus() on the frame and on the child window, and SetFocusIgnoringChildren on the chart's parent panel, and anything else I can think of with equal non-effect, I have no idea what to do next.

On Sat, May 30, 2009 at 8:19 AM, lostgallifreyan
<los...@gm...> wrote:
>
> I thought wxLua was a C-coded binary. But I did notice that the Lua script produced what appeared to be the same thing. I think you mentioned this a month or so back, but I still manage to get confused by this. How much of the wxLua editor is actually Lua?
All of it, except for command line processing.
>>>That fails too because it doesn't recognise spaces in file names! This is definitely not
>>> an improvement. While the script does open in wxLua, it won't run because even though
>>> it has it opened, it can't actually FIND it by file name to run it.
>>
>>Really? I have no problems opening files with spaces in its name.
>>Please give more details.
>
> Not much I can add, but there is some...
> I open the file "GPS Chart/lua" by manually browsing from the v2.10 wxLua, then try to run it from the Debug menu. A "wxLua Console" window pops up saying:
> Lua: Error occurred while opening file
> cannot open C:\WINDOWS\Desktop\GPS: No such file or directory
>
It is probably failing in the function "OpenFile(event)" or io.open()
in LoadFile() in editor.wx.lua. As you can see, there's no special
filename processing going on. Can you open the file if you hardcode
the path for io.open() in LoadFile()?
>>
>>> Another thing I have found is a failure in EVT_ERASE_BACKGROUND blocking. I'm getting
>>> flicker in something that didn't flicker in the previous release of wxLua. Note the two commented lines...
>>
Yes the static bitmap flickers. Why don't you draw it yourself like this?
function Main()
 FRAME=wx.wxFrame(wx.NULL,-1,"")
 FRAME:CreateStatusBar() FRAME:SetStatusText(" ")
 LAYER=wx.wxPanel(FRAME,-1) PANEL=wx.wxPanel(FRAME,-1)
--CHART=wx.wxStaticBitmap(PANEL,-1)
 FRAME:SetSize(800,600) FRAME:Centre()
 BITMAP=wx.wxBitmap("image.jpg")
 BX,BY,OX,OY,PX,PY=BITMAP:GetWidth(),BITMAP:GetHeight(),0,0,0,0
--CHART:SetBitmap(BITMAP)
 FRAME:Connect(wx.wxEVT_SIZE,OnSize)
 LAYER:Connect(wx.wxEVT_LEFT_DOWN,function(E)
PX,PY=OX-E:GetX(),OY-E:GetY() end)
 LAYER:Connect(wx.wxEVT_MOTION,OnMotion)
 LAYER:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end)
 PANEL:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end) --Either of
these ought to stop flicker but don't.
 --CHART:Connect(wx.wxEVT_ERASE_BACKGROUND,function() end) --Neither
of them are needed in earlier wxLua anyway.
 PANEL:Connect(wx.wxEVT_PAINT,OnPaint)
 FRAME:Show(true)
end
function OnPaint(E)
 local pdc = wx.wxPaintDC(E:GetEventObject():DynamicCast("wxWindow"))
 pdc:DrawBitmap(BITMAP, OX, OY, false)
 pdc:delete()
end
function OnSize(E)
 CX,CY=FRAME:GetClientSizeWH() PANEL:SetClientSize(CX,CY)
LAYER:SetClientSize(CX,CY) CX,CY=CX-BX,CY-BY
 if OX<CX then OX=CX end if OY<CY then OY=CY end LAYER:Refresh()
 PANEL:Refresh()
end
function OnMotion(E)
 if E:LeftIsDown() then
 OX,OY=PX+E:GetX(),PY+E:GetY()
 if OX>0 then OX=0 end if OY>0 then OY=0 end if OX<CX then
OX=CX end if OY<CY then OY=CY end
 --CHART:Move(OX,OY)
 PANEL:Refresh()
 end
end
Main()
Regards,
 John

On Sun, May 31, 2009 at 3:51 PM, lostgallifreyan
<los...@gm...> wrote:
> Smal update, which might confirm that it is broken in some way.
>
> I found that Raise() will work in my three-window test earlier described, in limkted circumstances. If I have called the Explorer window to the top by using Alt+Tab, I can move the pointer into the wxLua window, and Raise() will bring it to the top. If I click in the explorer window, it breaks Raise() so it fails. Lower() is not affected. I tried SetFocus(), and Show() but haven't yet found anything that acts as if a hovering pointer has clicked in the wxLua window. As clicking in it restores Raise() to working order, until a click is made in some other window, I guess a simulated click might do it. When I test it with drag/drop the results are unpredictable, not consistent, so it really looks broken to me, 'undefined behaviour'. Lower() is very simple, very consistent. Is there a reason why Raise() should not be equally so?
>
I don't really understand what you're trying to do. You first said
that Raise() works, but you couldn't make it active since there is no
function for this. I checked and I didn't see one either. Are you
really sure that that your UI can only work if you bring your app to
the foreground and make it active when the mouse go into the window?
What's wrong with the user dragging stuff onto the app and then
clicking the app the raise and focus it?
Regards,
 John