wxlua-users Mailing List for wxLua

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?

John Labenski <jla...@gm...> wrote:
(29/05/2009 21:00)

>> This looks like it should work, but it won't:
>>  INPUT:Connect(wx.wxEVT_ENTER_WINDOW,function(E)  FRAME:Show(true)  FRAME:Raise(true)  end)
[snip]
>>
>
>I don't know about this, you might have to call Raise() after the
>enter window event handler is finished, use a timer or a flag with an
>idle event. You might want to stick with your philosophy of letting
>the OS behave the way it wants to behave. :)
>

Philosophy is a very fickle thing...

Actually I reckon FRAME:Raise() is just broken because I tried something obvious that never occured to me yersterday: FRAME:Lower()
I omitted the FRAME:Show() for this, as well as when retrying Raise() in place of Lower()
I ran the script, put its window over another window (text editor), and an Explorer window, active, over most of the script's frame window. I then mouse-entered the INPUT panel area as before, and the inactive frame window jumped behind the text editor. If Lower() works, surely Raise() being the exact inverse should work too, but it doesn't.

Typo correction:
"GPS Chart/lua" should be "GPS Chart.lua"
No Windows machine would have let me use a / in a filename anyway..

John Labenski <jla...@gm...> wrote:
(29/05/2009 20:02)

>Please turn on your line wrap.
>

Can't.. nPOP (mail client I use) only does that for viewing, which I thought was kind of the point, a sending client can't know what size remote viewers will use, unless they're all the same. Actually, the Usenet client Xnews does set wrap on sent text, as do some others, and by the time a few posts get repeat quoted the result is scrambled to near illegibility, it's a terrible idea. :)

>>
>> The new error reporting method doesn't work well. While I know someone asked for
>> it to print messages to the console, that's broken more than it fixed. Now, if there's an
>> error, the program exits, reporting nothing. (I launch scripts by using WIndows to
>> associate them with wxLua.exe. If I try launching them from a commandline, nothing
>> is reported there either, so I try launching them from wxLua.exe directly.
>
>This is unfortunate. I use Cygwin as my console in MSW and it does
>provide stdout. GUI programs in MSW merely throw out anything written
>to stdout. There is nothing that we can do about that besides allocate
>our own DOS console, but this new console can only exist while the
>parent program is running. I think the best solution is to make using
>our own console standard in MSW since it will stay open until you
>close it. i.e. make "$wxlua.exe -c" the normal mode of operation in
>MSW, but only show the console when something is printed.
>

stdout might have worked ok but I think wxLua not actually being a consol app just got launced by the console then ran as it normally would. Ideally I think the answer is to have an INI file attached to wxLua and let us choose which method we want from each of those that have worked well.

>>This is clumsy, drag/drop won't work as it does if I launch by dragging to the file's icon
>> in a directory (but that doesn't report errors now). Dragging onto the pre-opened
>> wxLua fails because it's not enabled for drag/drop, so I must browse manually to the file.
>
>Fixes or additions to editor.wx.lua are welcome.
>

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? I wasn't sure it was within my reach to examine and fix internals of that one.. My guess is the script access core stuff in the binary, but it won't be the work of five minutes to figure out how much control we get from the script... I noticed same behaviour regarding space chars in either form, and putting the script out of reach of the binary implies that the common code handling that is in the binary anyway, so I have no fast way to figure out what I can control, and good reason to ask if I even can..


>>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

Lua: Error occurred while opening file

As you can see, it appears to have balked at the space. I double-checked that it IS a space. :) (Seriously, I was using a PPC for a while and beat just suck a problem as this by using char 160 to dupe that system into reading the whole name. Same trick fails in this case though, and actually causes the initial file load to fail also.

Note: System is W98 SE. Probably not significant though.




>> (How about an option to send error reports to a file? That way I can see them as before,
>> in a message box, but also have a written copy if I need one).
>
>$wxlua.exe myprogram.lua > outfile.txt
>

That's cool. Works too, wasn't expecting that as I thought it was purely a GUI program even if launched from a console. Might be nicer if we could choose such an option and leave it set in INI file though, as otherwise invoking this behaviour automatically demands some fancy footwork with the registry in Windows and might even conflict with command structures like those I use to associate data files with a script that is in turn associated with wxLua. Command lines can only do so much at one go..

>
>> 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...
>
>Please try to provide a minimal runnable sample. I see that you are
>still using the wxStaticBitmap, I assume the flicker you see is from
>that control?
>

I reduced as much as possible, I think. Context can only be stripped down to a limited extent. You need the code that moves the image, and which sets up the layer that takes input control, and that OnSize function is vital, it prevents the image from drawing all over the frame borders, by constraining it to draw on panels correctly sized. Changing any of that would mean writing an irrelevant sample.

Yes, it is that wxStaticBitmap, but it worked before, should work now. As far as I can tell, it looks like the error is in wxWidgets itself most likely, someone must have decided that it ought to allow background erasing, and enabled it but where last time it could not be enabled, this time it cannot be DISabled. >:) Eventually someone might notice. I might tell them, not sure if they'll listen to me though. Someone 'fixed' the spincontrol events a while back and actually broke what was more useful bahaviour before the fix! I spoke to Kevin Hook about it, and he said he's not involved now. Ò^O, I figured that if HE wasn't involved, I was about as close as the orbit of Jupiter.

My earlier sample is ready to run, just needs an edit to point to a big bitmap. (I didn't think people would take kindly to me attaching big bitmaps here. :)

On Fri, May 29, 2009 at 1:22 PM, lostgallifreyan
<los...@gm...> wrote:
> This looks like it should work, but it won't:
>  INPUT:Connect(wx.wxEVT_ENTER_WINDOW,function(E)  FRAME:Show(true)  FRAME:Raise(true)  end)
>
>
> INPUT is a panel. I've confirmed it works. Actually the enter event is only detected when I let go the dragged file, but that's ok. Trouble is, nothing will set it active. wxWidegts appears to offer no SetActive(), and 'focus' seems to mean something specific to text fields, and there seems to be no way to directly call a frame to appear on top if the pointer is moved into either the frame or a child window. I can make all kinds of stuff happen, but not that. Searching for 'on top', or 'bring to front' and all manner of similar queries draw blanks.
>

I don't know about this, you might have to call Raise() after the
enter window event handler is finished, use a timer or a flag with an
idle event. You might want to stick with your philosophy of letting
the OS behave the way it wants to behave. :)

Regards,
    John

On Fri, May 29, 2009 at 3:45 PM, Ana Eun Mi Lee <an...@gm...> wrote:
> Hi,
>
> I am trying to port wxLua to Windows CE.
>
> I know that wxWidgets supports Windows CE because I have already compiled
> wxWidgets libraries to Windows CE and they worked.
>
> Can anyone tell me if it is possible to port wxLua to Windows CE?

I don't see why it wouldn't work... after fixing up the bindings, of
course. I do not have any #ifdefs for Windows CE. The core of wxLua
shouldn't have any issues I would imagine?

Note that, for a quick initial test, when you compile wxLua and get
errors in the bindings you can really just rem out huge chunks of it
just to see how far you can get, basically make them noop functions.
You'll be breaking these functions if you try to call them from Lua,
but it might be worth your time to do this quick test to see how far
you can get compiling the C++ code. Also edit
modules/wxbind/setup/wxluasetup.h as necessary to turn off features
that you already know don't exist in CE.

Good luck,
    John

On Fri, May 29, 2009 at 1:49 PM, Pázmándi Attila
<ejj...@gm...> wrote:
> Hello!
> First of all, thanks for the new release! Nice to see this :) I downloaded
> the newest version, included the wxmsw28_vc_custom.dll in my application,
> everything works well. But. I checked wxlua.wxLUA_VERSION_STRING and
> wx.wxVERSION_STRING, I got 2.8.7.0 and 2.8.7. They aren't updated?

I can't reproduce this. I just downloaded wxLua-2.8.10-MSW-dll.zip and
checked and both say 2.8.10.

> About error reporting: Use xpcall(), and it will catch every error, that's
> how I do now:
...
> and main function is called by xpcall(main,OnError)
> Hope this helps.. :)

This is a good idea. However, I am going to revert the change to
wxlua.exe always print to stdout since I did not realize how broken
the MSW console is. In the meantime you may want to always run
$wxlua.exe -c to get a read-only textbox with the output shown.

Regards,
    John

Hi,

I am trying to port wxLua to Windows CE.

I know that wxWidgets supports Windows CE because I have already compiled
wxWidgets libraries to Windows CE and they worked.

Can anyone tell me if it is possible to port wxLua to Windows CE?

Thanks,

Ana

On Thu, May 28, 2009 at 8:05 AM, lostgallifreyan
<los...@gm...> wrote:
>

Please turn on your line wrap.

>
> The new error reporting method doesn't work well. While I know someone asked for
> it to print messages to the console, that's broken more than it fixed. Now, if there's an
> error, the program exits, reporting nothing. (I launch scripts by using WIndows to
> associate them with wxLua.exe. If I try launching them from a commandline, nothing
> is reported there either, so I try launching them from wxLua.exe directly.

This is unfortunate. I use Cygwin as my console in MSW and it does
provide stdout. GUI programs in MSW merely throw out anything written
to stdout. There is nothing that we can do about that besides allocate
our own DOS console, but this new console can only exist while the
parent program is running. I think the best solution is to make using
our own console standard in MSW since it will stay open until you
close it. i.e. make "$wxlua.exe -c" the normal mode of operation in
MSW, but only show the console when something is printed.

>This is clumsy, drag/drop won't work as it does if I launch by dragging to the file's icon
> in a directory (but that doesn't report errors now). Dragging onto the pre-opened
> wxLua fails because it's not enabled for drag/drop, so I must browse manually to the file.

Fixes or additions to editor.wx.lua are welcome.

>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.

> (How about an option to send error reports to a file? That way I can see them as before,
> in a message box, but also have a written copy if I need one).

$wxlua.exe myprogram.lua > outfile.txt


> 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...

Please try to provide a minimal runnable sample. I see that you are
still using the wxStaticBitmap, I assume the flicker you see is from
that control?

Regards,
    John

Hello!
First of all, thanks for the new release! Nice to see this :) I downloaded
the newest version, included the wxmsw28_vc_custom.dll in my application,
everything works well. But. I checked wxlua.wxLUA_VERSION_STRING and
wx.wxVERSION_STRING, I got 2.8.7.0 and 2.8.7. They aren't updated?

About error reporting: Use xpcall(), and it will catch every error, that's
how I do now:
function OnError(errorstr)
    local file = io.open("./exceptioninfo.txt","a+")
    if file then
        local tUptime = os.date("*t",os.clock())
        file:write("System informations: \n"..
        " Time: "..os.date("%x %X").."\n"..
        " OS: "..wx.wxGetOsDescription().."\n"..
        " Free memory: "..(tFuncs and
tFuncs:ConvertShare(wx.wxGetFreeMemory():ToDouble()) or
(wx.wxGetFreeMemory():ToDouble().." B")).."\n"..
        " Startup path: "..wx.wxGetCwd().."\n"..
        " Resolution:
"..wx.wxGetDisplaySize():GetWidth().."x"..wx.wxGetDisplaySize():GetHeight().."\n"..
        " Uptime: "..string.format("%i hour(s) %i minute(s) %i
second(s)",tUptime.hour,tUptime.min, tUptime.sec).."\n"..
        " Program version: ".._APPVER.."\n"..
        " LUA version: ".._VERSION.."\n"..
        " wxWidgets version: "..wx.wxVERSION_STRING.."\n"..
        " wxLUA version: "..wxlua.wxLUA_VERSION_STRING.."\n"..
        string.rep("=",60).."\nError message
description:\n"..tostring(errorstr).."\n"..
        debug.traceback().."\n")
        file:write(string.rep("=",60).."\n")
        file:close()
        wx.wxMessageBox("An error occured in the application, some
information about it has been generated. \n"..
        "Please send the exceptioninfo.txt file to: mya...@gm...
","ERROR",wx.wxICON_ERROR)
    else
        wx.wxMessageBox("An error occured in the application, but the
program can't write into the debug file. \n"..
        "Hence, I can't find out why it crashed, so don't report this as a
bug unless you find a solution...","ERROR",wx.wxICON_ERROR)
    end
    tCtrls["app"]:Destroy()
    wx.wxGetApp():ExitMainLoop()
    wx.wxExit(0)
end

and main function is called by xpcall(main,OnError)
Hope this helps.. :)

This looks like it should work, but it won't:
  INPUT:Connect(wx.wxEVT_ENTER_WINDOW,function(E)  FRAME:Show(true)  FRAME:Raise(true)  end)


INPUT is a panel. I've confirmed it works. Actually the enter event is only detected when I let go the dragged file, but that's ok. Trouble is, nothing will set it active. wxWidegts appears to offer no SetActive(), and 'focus' seems to mean something specific to text fields, and there seems to be no way to directly call a frame to appear on top if the pointer is moved into either the frame or a child window. I can make all kinds of stuff happen, but not that. Searching for 'on top', or 'bring to front' and all manner of similar queries draw blanks.

John Labenski <jla...@gm...> wrote:
(28/05/2009 23:56)

>> PATH=string.gsub(arg[0],"^(.+[/\\]).+$","%1").."Bitmaps/"
>>
>> It works, but it's a clumsy method. At least it's portable, it accepts non-Windows path separators...
>
>This is a typical problem of finding where a program's external
>resources are and is not unique to wxLua or Lua. The way you do it is
>pretty a pretty standard way. You may want to create a shortcut to
>your app and set the "Start In" path to the directory of the program
>and its resources.
>

Ok, I guess not everything native to the OS is lovely. :) Shortcuts are binaries, they break at times (especially if triggered accidentally when they can't find the file they want...), I learned to avoid them except for simple stuff like drag-generated shortcuts made from existing files on demand.

I'll stay with the method I worked out because that way I can separate the path and filename from the string, and I know I'll be wanting that done anyway for various things. Just need to use gfind instead of gsub to fetch both parts to variables.

On Thu, May 28, 2009 at 11:19 AM, lostgallifreyan
<los...@gm...> wrote:
> This appears with both the older and latest wxLua, and might even be native to Lua, but I don't think so.
>
> If I open a data file in the same location as the script, bitmaps for toolbar buttons in a subdirectory are found, if I open a data file elsewhere, they are not! That means that the data file path, not the script file path, is being assumed to be the working directory, which is definitely odd. (This is my best assumption anyway, I don't know how to prove it because if I ask it to print the path, it just prints what I told it, not the expanded path it tried to use).
>
> Normally I could do this:
> PATH="./Bitmaps/"
>
> But for now I have to do this to force wxLua to look at the right path to chose as working directory:
> PATH=string.gsub(arg[0],"^(.+[/\\]).+$","%1").."Bitmaps/"
>
> It works, but it's a clumsy method. At least it's portable, it accepts non-Windows path separators...

This is a typical problem of finding where a program's external
resources are and is not unique to wxLua or Lua. The way you do it is
pretty a pretty standard way. You may want to create a shortcut to
your app and set the "Start In" path to the directory of the program
and its resources.

Regards,
    John Labenski

This appears with both the older and latest wxLua, and might even be native to Lua, but I don't think so.

I'm using the Windows registry to associate files, such that I right click on a data file, select an option I put there to open it with a script I associated it with, the script in turn being associated with wxLua. This normally works fine (excepting problems noted earlier in other post about latest wxLua..).

If I open a data file in the same location as the script, bitmaps for toolbar buttons in a subdirectory are found, if I open a data file elsewhere, they are not! That means that the data file path, not the script file path, is being assumed to be the working directory, which is definitely odd. (This is my best assumption anyway, I don't know how to prove it because if I ask it to print the path, it just prints what I told it, not the expanded path it tried to use).

Normally I could do this:
PATH="./Bitmaps/"

But for now I have to do this to force wxLua to look at the right path to chose as working directory:
PATH=string.gsub(arg[0],"^(.+[/\\]).+$","%1").."Bitmaps/"

It works, but it's a clumsy method. At least it's portable, it accepts non-Windows path separators...

John Labenski <jla...@gm...> wrote:
(24/05/2009 17:40)

>
>We are pleased to announce the latest release of wxLua.
>
>wxLua 2.8.10.0 is a stable bugfix release that is a minor update to
>the internals of wxLua and the precompiled versions are linked against
>wxWidgets 2.8.10.
>


Thanks for keeping it going. Got some trouble though.. For now I'll have to stay with wxLua v2.8.7.0.


The new error reporting method doesn't work well. While I know someone asked for it to print messages to the console, that's broken more than it fixed. Now, if there's an error, the program exits, reporting nothing. (I launch scripts by using WIndows to associate them with wxLua.exe. If I try launching them from a commandline, nothing is reported there either, so I try launching them from wxLua.exe directly. This is clumsy, drag/drop won't work as it does if I launch by dragging to the file's icon in a directory (but that doesn't report errors now). Dragging onto the pre-opened wxLua fails because it's not enabled for drag/drop, so I must browse manually to the file. 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. Please let us use our OS's inbuilt tools to handle this stuff, it's a better way, usually, as it works for everything we do with the OS as well. Right now we can't if we want error reporting. (How about an option to send error reports to a file? That way I can see them as before, in a message box, but also have a written copy if I need one).



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...



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()  FRAME:Show(true)

  BITMAP=wx.wxBitmap("Some Really Big Full Colour Bitmap.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.
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)  LAYER:Refresh()
  end
end

Main()

On Tue, May 26, 2009 at 11:36 AM, Leslie Newell
<les...@fa...> wrote:
> Are there any plans to support wxWidgets 2.9.x in the near future? Or
> does it work already?

Yes, I am gearing up for trying it out. I know that there might be a
small issue with the char* <--> wxString functions wx2lua() and
lua2wx(), but this should be minor as 2.9 uses UTF8 now. Other than
that, there will probably be a handful of changes to other functions.

In the big scheme of things I plan on trying to use the interface
files that wxWidgets now uses for generating the docs as the interface
files that wxLua uses to generate the bindings. That, however, will be
a big job, but hopefully worth it as I will not have to try to
maintain our own copy of them.

Regards,
    John

Are there any plans to support wxWidgets 2.9.x in the near future? Or
does it work already?

Thanks,
Les

We are pleased to announce the latest release of wxLua.

wxLua 2.8.10.0 is a stable bugfix release that is a minor update to
the internals of wxLua and the precompiled versions are linked against
wxWidgets 2.8.10.

-------------------------------------------------------------------------------
wxLua is a Lua scripting language wrapper around the wxWidgets
cross-platform GUI library. It consists of an executable for running
standalone wxLua scripts and a library for extending C++ programs with
a fast, small, fully embeddable scripting language.

References:
http://wxlua.sourceforge.net
http://www.lua.org
http://www.wxwidgets.org

-------------------------------------------------------------------------------
The wxLua "big picture"

Lua is an ANSI C compatible scripting language that can load and run
interpreted scripts as either files or strings. The language itself is
very dynamic and contains a limited number of data types, mainly
numbers, strings, and tables. Perhaps the most powerful feature of the
Lua language is that the tables can be used as either arrays or as
hashtables that can contain numbers, strings, and/or subtables.

wxLua adds to this small and elegant language the power of the
wxWidgets cross-platform GUI library. This includes the ability to
create complex user interface dialogs, image manipulation, file
manipulation, sockets, displaying HTML, and printing to name a few.

-------------------------------------------------------------------------------

 wxLua ChangeLog
 ===============

 version 2.8.10.0  (released 05/25/2009)
 --------------------------------------------------------------------

 - Updated Lua to 5.1.4

 * Changed the %typedef binding to work as the C/C++ typedefs work.
   The usage is reversed from how it was in previous versions.
   You will need to swap the parameters for it in your bindings.
   Example: %typedef long wxTextCoord
 - Added more C/C++ operators in the bindings.
 - wxLuaEdit now prints values in the console like the Lua executable.
 * Changed signature of wxLuaState::RunBuffer() to take a const char*
   instead of an const unsigned char*, cast to (const char*) as appropriate.
 - Allow wxLuaState::RunString/Buffer() and friends to allow for values left
   on the stack. The default is to leave none as before.
 - Added wxTextUrlEvent to the bindings.
 - Fixed double -> unsigned integer using all 32 bits conversion.
   Fixes wxSTC_MASK_FOLDERS problem, thanks to Andre Arpin.
 - Allow multiple inheritance in the bindings. Changed members of
   wxLuaBindClass to reflect that base class info are stored in arrays.


Regards,
    John Labenski

Ok, I found an answer:
wx.wxSystemOptions.SetOption("msw.remap",1)

wxWidgets manual says this is enabled by default. It isn't.

wxLua v2.5.4 let me make bitmaps for toolbar buttons where black would take the system foreground text colour, and grey (192,192,192) would take the background colour, and one or two other colours took similar changes. Similar things still result in the Scribble program where wxArtProvider provides the images, but if you add a pre-loaded bitmap with TOOLS:AddTool(-1,"",BITMAP,"Tooltip Text") it won't show system colours as it used to.

I've looked at everything I can find related to 'themes' as the wxWidgets manual calls the colour schemes used in Windows, stuff like TOOLS:SetBackgroundStyle(wx.wxBG_STYLE_SYSTEM) or TOOLS:SetThemeEnabled(true), and nothing makes it work, or even seems to have any effect on anything.

John Labenski a écrit :
>
> I'm not sure I understand. GUI programs usually don't work this way, 
> they are event loop based and therefore they are not sequential. If 
> you want to pop up a dialog that is non-modal simply use 
> wxDialog:Show(true) instead of ShowModal().
I'm not used to GUI programs, but the fact that they "usually [...] are 
event loop based" does not mean it is the best solution :-) Lua provides 
an interesting tool that do not exist natively in C (the coroutines), 
and that can, in my opinion, help make programs easier to write and 
easier to read. Maybe its a bad idea, but until now, it works fine for 
me, excepted this callback problem. I've solved the problem by creating 
a small module that allows to execute, from a coroutine, a function in 
the main thread. It helps to keep the main thread code independant from 
the coroutine code. My application works fine now, thanks for the help.

Youen Toupin <you...@wa...> wrote:
(19/05/2009 19:22)

>lostgallifreyan a écrit :
>> When I was looking at it I was wondering where and how I'd pass a returned value if I had to, which sort of fits with what you just said. I've never used a co-routine yet, but if I do, is it right to consider it purely as a sub-routine that happens to use a separate thread, and not to concern myself with the underlying methods that make it so?
>>   
>A coroutine is not a thread, it will not run in parallel of anything 
>else. It is similar to a thread because when you call coroutine.yield(), 
>it will resume the execution of the main thread, the coroutine is 
>paused, its callstack is preserved. Then you can call coroutine.resume( 
>yourCoroutine ) to resume the execution of the coroutine just after the 
>call to coroutine.yield. For example, if you call coroutine.yield() very 
>often, and resume the coroutine from a main loop, this will give a 
>parallel-like execution of the main loop and the coroutine.
>

I only recently adapted to the message loop. :) I'm not yet sure how I can use co-routines, though I think they're native to Lua, so would it be useful to make something that behaves like a message loop in Lua? Before I start exploring them, I really need to know what might make them indispensible, either impossible by other ways, or at least not done as well otherwise. I'm also unsure how it shows parallel-like behaviour if it does not run parallel to anything else, except in the sense of multiplexing, which is what multi-threading is also.

>I'm not sure to understand your question about the return value, but if 
>you want to pass a return value from a coroutine to the main thread, you 
>can. It is the last coroutine.resume called by the main thread that will 
>get the result. You can not get the result at the location where you 
>initially started the coroutine however.
>

Understood. I think. So not at all like a subroutine or called function that passes back values. I guess one way is a global that gets examined periodically by other code for any value a co-routine puts in it might be a useful trick.

John Labenski <jla...@gm...> wrote:
(20/05/2009 01:24)

>On Tue, May 19, 2009 at 2:14 PM, Youen Toupin <you...@wa...>wrote:
>
>> John Labenski a écrit :
>> > I think that all you need to do is to shuffle around your existing
>> > code to pull out the dialog creation from the coroutine code, I also
>> > demonstrate how to pass data around without using globals.
>> Yes, this is a solution, but I would like to avoid it if possible. My
>> idea is to use coroutines to have a flexible system that would allow
>> sequential programming to perform tasks even when these tasks require
>> user action, or waiting for anything without blocking the application.
>> The promptUser function is only an example. I'd like to be able to write
>> things like:
>>
>
>I'm not sure I understand. GUI programs usually don't work this way, they
>are event loop based and therefore they are not sequential. If you want to
>pop up a dialog that is non-modal simply use wxDialog:Show(true) instead of
>ShowModal().
>

Not that I think my knowledge is enough to warrant high observance, but I back this up. I said this earlier too. I'm recently learning C (on TCC compiler, using API), and learned that wxLua (at least, wxWidgets is so both) is very like C being based in it. Modeless dialogs will sit and wait while the rest of program hangs on every word otherwise uttered by the event loop. I used to hate this concept, being taught on linear sequences that always had to halt while waiting for input, but now I really like this event loop thing.

On Tue, May 19, 2009 at 2:14 PM, Youen Toupin <you...@wa...>wrote:

> John Labenski a écrit :
> > I think that all you need to do is to shuffle around your existing
> > code to pull out the dialog creation from the coroutine code, I also
> > demonstrate how to pass data around without using globals.
> Yes, this is a solution, but I would like to avoid it if possible. My
> idea is to use coroutines to have a flexible system that would allow
> sequential programming to perform tasks even when these tasks require
> user action, or waiting for anything without blocking the application.
> The promptUser function is only an example. I'd like to be able to write
> things like:
>

I'm not sure I understand. GUI programs usually don't work this way, they
are event loop based and therefore they are not sequential. If you want to
pop up a dialog that is non-modal simply use wxDialog:Show(true) instead of
ShowModal().

In any case, if you really want to use coroutines you can use the below. I
think your problem was simply that you were calling coroutine.resume from
within the coroutine so all the code does below is make sure that the
callback() function which will call coroutine.resume() is called from the
main Lua state. I would probably go with the c_fn() way, which would allow
you to use far more local vars, but you'll have to make quite a few more
mods to pass more data around as params before you can get rid of all the
globals...

Regards,
    John

==============================
-- I overwrite print and assert functions to get messages in the console
window
--local print = print -- don't want wxLua print function
local assert = function( cond, msg, ... )
   if not cond then
       print( "Assertion failed: "..msg )
       print( debug.traceback() )
   end
   return cond, msg, ...
end

require( "wx" )

function callback()
   print( "Button clicked" )
   assert( coroutine.resume( co ) )
end

function connect_fn()
    dialog:Connect( button:GetId(), wx.wxEVT_COMMAND_BUTTON_CLICKED,
callback )
end

function createDialog()
   dialog = wx.wxDialog( wx.NULL, wx.wxID_ANY, "Test dialog",
wx.wxDefaultPosition, wx.wxDefaultSize )
   panel = wx.wxPanel( dialog, wx.wxID_ANY )
   sizer = wx.wxBoxSizer( wx.wxHORIZONTAL )
   button = wx.wxButton( panel, wx.wxID_ANY, "Test button" )
   sizer:Add( button )

   panel:SetSizer( sizer )
   sizer:SetSizeHints( dialog )
   dialog:Show( true )
end

co = coroutine.create( function()
   createDialog()
   print( "Yield..." )
   coroutine.yield(connect_fn)
   print( "After yield" )
   coroutine.yield()
   print( "After yield 2" )
   coroutine.yield()
   print( "After yield 3" )
end )

ret, c_fn = coroutine.resume( co )
print(ret, c_fn, dialog, button)

-- each of these ways works
--c_fn()
--dialog:Connect( button:GetId(), wx.wxEVT_COMMAND_BUTTON_CLICKED, callback
)
connect_fn()

wx.wxGetApp():MainLoop()

lostgallifreyan a écrit :
> When I was looking at it I was wondering where and how I'd pass a returned value if I had to, which sort of fits with what you just said. I've never used a co-routine yet, but if I do, is it right to consider it purely as a sub-routine that happens to use a separate thread, and not to concern myself with the underlying methods that make it so?
>   
A coroutine is not a thread, it will not run in parallel of anything 
else. It is similar to a thread because when you call coroutine.yield(), 
it will resume the execution of the main thread, the coroutine is 
paused, its callstack is preserved. Then you can call coroutine.resume( 
yourCoroutine ) to resume the execution of the coroutine just after the 
call to coroutine.yield. For example, if you call coroutine.yield() very 
often, and resume the coroutine from a main loop, this will give a 
parallel-like execution of the main loop and the coroutine.

I'm not sure to understand your question about the return value, but if 
you want to pass a return value from a coroutine to the main thread, you 
can. It is the last coroutine.resume called by the main thread that will 
get the result. You can not get the result at the location where you 
initially started the coroutine however.