wxlua-users Mailing List for wxLua

Any advice about this one?
First, I tried making a tooltip as specified on the wx.chm page for wxToolTip as follows, and played with that a bit...
function Main()
 local XX=wx.wxToolTip("xcv")
 XX:SetTip("Zoodle\nWurdle")
 print(XX:GetTip()) --prints "Zoodle" and on new line, "Wurdle"
 print(XX:GetWindow()) --prints 'nil'.
end
Main()
I'm not sure that there is a way to attach a preconstructed tootltip to a window. I couldn't find one. Setting XX:Enable(true) (or false) and XX:SetDelay(5) failed, with some confusion about what arguments were passed.
Then I tried something based on the methods shown in the Scribble example. That works, given some care, but I'm not sure that it will continue to work if any work is done on wxLua's tooltip internals...
function OnMotion(E)
 if E:LeftIsDown() then
 PANEL:SetToolTip("")
 else
 PANEL:SetToolTip("X = "..E:GetX().."\nY = "..E:GetY())
 end
end
This is a multiline tooltip showing the current co-ordinates for the pointer/cursor. It's designed to stay visible, tracking the pointer motion, and to instantly vanish if some condition is met, and reappear if the condition reverts.
Two things to watch for:
1. The spaces each side of the displayed "=" signs are character ASCII 160, to prevent the spaces breaking the line. With real ones the tooltip forces the narrowest vertical form possible treating spaces as extra line breaks! (Provided that one real line break is in the string).
2. If I restarted the script after reversing the PANEL:SetToolTip() lines above, (or leaving them as is, but entering the displayed panel region for the first time with the left button already held down), a subsequent reverse of button state, while showing the tooltip as it should, produced a single-line tip, with the \n rendered as a small block such as a control cnaracter might be shown if present. I fixed this by the odd method of adding a line in the Main() function:
PANEL:SetToolTip(" \n").
This form is crucial for the first 'appearance' of any tooltip (it is not, (as is desired), actually seen at that point), the \n forces the later tooltips to be multiline, and the space (real this time) prevents it from later only showing a tiny vestigial block a couple of pixels high and wide when it's supposed to show a full multiline message.
For now the described method works well, but it strongly suggests that it's more by luck than a clearly defined behaviour, and if there is a better way to enforce the behaviour I want (described, and illustrated by these code examples when using wxLua v2.8.7.0), please tell me what it is.
PS. John, I posted that earlier reply to your reply via Gmane because I was still not getting any emails from the list, Gmane (and similar archives sites) is my only way to see, or respond, to the list, and I think Gmail was the main culprit judging by losses and delays of other stuff. I'm not sure if you saw my response. (It basically said thanks for the for loop to traverse a table of user data objects (very useful test flag I since added to my collection), and ended with a longish query about Windows' apparent delayed clearup of large image loads, with a query about whether wxLua, like Paint Shop, can be set to somehow allow any number of such loads without the image failing to render after just one or two attempts).

John Labenski <jlabenski@...> writes:
>
> On Sat, Apr 25, 2009 at 1:11 PM, lostgallifreyan
> <lostgallifreyan@...> wrote:
.
.
> > local DC,P=wx.wxMemoryDC(),wx.wxPen() P:SetWidth(5) P:SetStyle(wx.wxSOLID)
> > DC:SelectObject(BITMAP) DC:SetPen(P) DC:SetBrush(wx.wxTRANSPARENT_BRUSH)
> > for N=0,255,5 do
> > P:SetColour(N,N,N) DC:SetPen(P) DC:DrawLine(N,0,N,100)
> > end
> > DC:SelectObject(wx.wxNullBitmap) P:delete()
> > DC:delete()
> >
>
> The code above is fine since the C++ wxPen::SetColour() code simply
> calls wxColour::Set(r,g,b) on the internal wxColour member of the
> wxPen. More generally; in wxLua you don't have to worry about deleting
> any objects that are not explicitly created by you in wxLua or
> returned by another function. We will trust that there are no memory
> leaks in wxWidgets itself, which is a safe bet.
>
Cool, I guess that means I'd have to watch it if I used GetColour(),
as in that case I'd have an actual colour object on my hands if I
didn't extract its values then immediately delete it.
> You can print out all the objects in wxLua including ones that are
> installed at startup:
> for k,v in pairs(wxlua.GetTrackedObjectInfo()) do print(k, v) end
>
> and also only the objects that you have created that need to be or
> will be deleted when they go out of scope and the garbage collector
> runs:
> for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
>
> ========================
> example in wxLuaEdit in the console in the bottom:
>
> p = wx.wxPen(wx.wxColour(1,2,3), 1, 1)
> for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
> 1 wxColour(0x29846f0)
> 2 wxPen(0x2952780)
> collectgarbage('collect')
> for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
> 1 wxPen(0x2952780)
>
Very nice. Thankyou. I'll add those to my collection of test flags. :)
> The most "dangerous" problem with GC in wxLua are those hidden objects
> like the wxColour above and there's no way to keep track of them. I
> can't think of any clever way that would be much better than simply
> calling the Lua function collectgarbage("collect").
>
Fine by me, it's built into Lua's core so I want to learn its use anyway.
Your advice will help me find the time and place to do it.
One thing I've noticed is that when loading a large bitmap, I get one or
two shots at it providing each load and close of the program is clean.
If I try too soon the bitmap loads but is not displayed! Conversely if I
leave the program sitting for a while, I can expect to close and reload
and have it display more that twice per session without reboot. If it borks
and fails to display, that's it, end of session, need reboot. (This is W98
SE). I have tried collectgarbage("collect") at various points already during
yesterday's work, without results, but the fact that I can wait a while and
thus get clearance to load it again safely imp;ies that some sort of garbage
collection might be happening, and possibly in Windows itself? If you have
any thoughts that might help track down a way to invoke it manually, it coule
allow me to safely load a huge image any number of times without causing that
display failure. One other clue: I've seen similar errors in other programs,
which is why I'm convinced this is something in Windows. Crucially, tools
like Paint Shop appear to be able to reload the image as often as I like
without error, so that implies there IS a way, though whether it's something
wxLua can reach I don't know yet.

On Sat, Apr 25, 2009 at 1:11 PM, lostgallifreyan
<los...@gm...> wrote:
> I'd been creating and deleting pens and colours each time round a loop to avoid accumulations, and returned to this issue while seeking ways to speed up my program.
>
> My current attempt is this (with irrelevance stripped out):
>
> local DC,P=wx.wxMemoryDC(),wx.wxPen() P:SetWidth(5) P:SetStyle(wx.wxSOLID)
> DC:SelectObject(BITMAP) DC:SetPen(P) DC:SetBrush(wx.wxTRANSPARENT_BRUSH)
> for N=0,255,5 do
>  P:SetColour(N,N,N) DC:SetPen(P) DC:DrawLine(N,0,N,100)
> end
> DC:SelectObject(wx.wxNullBitmap) P:delete()
> DC:delete()
>
> It works, but I'm not sure that it's safe. is P:SetColour() changing an implied colour 'object' that would better be made explicit and assigned to a vartiable so I can delete it along with the pen after the loop ends? The wx.chm manual doesn't make this clear, it seems to imply that this method avoids the need for an actual colour 'object' entirely.
>
The code above is fine since the C++ wxPen::SetColour() code simply
calls wxColour::Set(r,g,b) on the internal wxColour member of the
wxPen. More generally; in wxLua you don't have to worry about deleting
any objects that are not explicitly created by you in wxLua or
returned by another function. We will trust that there are no memory
leaks in wxWidgets itself, which is a safe bet.
You can print out all the objects in wxLua including ones that are
installed at startup:
for k,v in pairs(wxlua.GetTrackedObjectInfo()) do print(k, v) end
and also only the objects that you have created that need to be or
will be deleted when they go out of scope and the garbage collector
runs:
for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
========================
example in wxLuaEdit in the console in the bottom:
p = wx.wxPen(wx.wxColour(1,2,3), 1, 1)
for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
1	wxColour(0x29846f0)
2	wxPen(0x2952780)
collectgarbage('collect')
for k,v in pairs(wxlua.GetGCUserdataInfo()) do print(k, v) end
1	wxPen(0x2952780)
The most "dangerous" problem with GC in wxLua are those hidden objects
like the wxColour above and there's no way to keep track of them. I
can't think of any clever way that would be much better than simply
calling the Lua function collectgarbage("collect").
Regards,
 John

I'd been creating and deleting pens and colours each time round a loop to avoid accumulations, and returned to this issue while seeking ways to speed up my program.
My current attempt is this (with irrelevance stripped out):
 local DC,P=wx.wxMemoryDC(),wx.wxPen() P:SetWidth(5) P:SetStyle(wx.wxSOLID)
 DC:SelectObject(BITMAP) DC:SetPen(P) DC:SetBrush(wx.wxTRANSPARENT_BRUSH)
 for N=0,255,5 do
 P:SetColour(N,N,N) DC:SetPen(P) DC:DrawLine(N,0,N,100)
 end
 DC:SelectObject(wx.wxNullBitmap) P:delete()
 DC:delete()
It works, but I'm not sure that it's safe. is P:SetColour() changing an implied colour 'object' that would better be made explicit and assigned to a vartiable so I can delete it along with the pen after the loop ends? The wx.chm manual doesn't make this clear, it seems to imply that this method avoids the need for an actual colour 'object' entirely.