wxlua-users Mailing List for wxLua

Hi John,
> Interesting, but that means that they're emulating the removed functions and I wonder what their setfenv() does.
Right; the code for setfenv is here:
https://github.com/corsix/twoface/blob/master/twoface.c#L492-L532
> In 5.2 setfenv() function was removed and the environment for a function is set by the _ENV table which should be the first upvalue for the function. I believe that this is automatic so the 5.2 behavior should be more expected, but I haven't rigorously tested what happens with callbacks in modules or even if you swap out the _ENV before setting the callback.
> http://stackoverflow.com/questions/14290527/recreating-setfenv-in-lua-5-2
yes, I'm familiar with this logic (in fact, one of the answers is
mine), but only on the Lua side. I'm not sure how it maps to C calls.
> Is there any way to detect when the twoface DLL is being used so that the code can take the 5.2 path?
Possibly, but I can't answer that question.
> Or maybe compile wxLua for 5.2 and use woface to treat 5.1 as 5.2 instead of the other way around.
No, this won't work as Twoface only works one way (mapping 5.1 calls
to 5.2 engine).
For now I patched my build process to remove those fragments and so
far have been running with twoface and Lua 5.2 without issues. I'm
still not sure what that fragment I removed does as my event callbacks
use various upvalues and seem to work correctly without that setfenv
check (and they were throwing the error before I removed the checks),
which makes me think that the check is not really needed.
I'll leave the decision up to you and let you know if I run into any
issues, but so far I only have two patches that make my wxlua
libraries deviate from yours: this change (not deployed yet) and the
live coding fix I applied
(http://comments.gmane.org/gmane.comp.lib.wxwidgets.wxlua.user/3273).
Actually, there is one more interesting issue, related to the live
coding fix. I'll describe it briefly here, maybe you can add some
details to it.
The classes you create in wxlua conveniently allow additional
properties to be assigned to them. For example, I can do "local editor
= wxstc.wxStyledTextCtrl(...)" and then "editor.foo = 'bar'" and it
all works. However, if I then try to access editor.foo from *another*
coroutine, it doesn't "see" that property and I get "wxLua: Unable to
call an unknown method ..." error, even though the property is there.
I haven't been able to figure out where exactly it fails and for now I
just worked around these cases, but it would be great if this could be
fixed (if there is a fix for that).
Ideally, editor.foo should return nil and editor.foo() should return
an error, but the comment you have in the code seems to point out that
it may not be possible to distinguish between these two cases. I think
it's because in editor.foo(), it gets the value of editor.foo first
and then calls it as a function. I'll be fine if it returns `nil` and
then fails on the function call.
Paul.
On Sat, Jul 20, 2013 at 11:26 AM, John Labenski <jla...@gm...> wrote:
>
> On Fri, Jul 19, 2013 at 7:54 PM, Paul K <pau...@ya...> wrote:
>>
>> Hi John,
>>
>> I've been looking into using twoface ABI mapper
>> (http://corsix.github.io/twoface/) to run ZeroBrane Studio on top of
>> Lua 5.2 without recompiling wxlua and luasocket (both are compiled for
>> Lua 5.1). For those not familiar with it, it allows to run Lua 5.2
>> engine with modules compiled for Lua 5.1 without any changes to those
>> modules. In my case, I use it with ZBS that is compiled for Lua 5.1
>> and can make it run with Lua 5.2 by replacing lua51.dll with a
>> different one (and adding lua52.dll).
>>
>
> Interesting, but that means that they're emulating the removed functions and
> I wonder what their setfenv() does.
>
>
>>
>> I have been able to run it with wxlua, but I ended up patching wxlua
>> in one place. For some reason when I ran it originally, I was getting
>> "wxLua: wxEvtHandler::Connect() in wxLuaEventCallback::OnEvent(),
>> callback function is not a Lua function." messages in more or less
>> random places. This error comes from an event handler check in
>> wxlcallb.cpp and it appears to be only active for Lua 5.1:
>>
>> #if LUA_VERSION_NUM < 502
>> // lua_setfenv() is not in Lua 5.2 nor can you set an env for
>> a function anymore
>> wxlState.GetGlobals();
>> if (wxlState.lua_SetFenv(-2) != 0)
>> #endif // LUA_VERSION_NUM < 502
>> {
>> // Don't track the wxEvent since we don't own it and tracking
>> it
>> // causes clashes in the object registry table since many can
>> be
>> // created and deleted and the mem address is resused by C++.
>> wxlState.wxluaT_PushUserDataType(event, event_wxl_type,
>> false);
>> wxlState.LuaPCall(1, 0); // one input no returns
>> }
>> #if LUA_VERSION_NUM < 502
>> else
>> wxlState.wxlua_Error("wxLua: wxEvtHandler::Connect() in
>> wxLuaEventCallback::OnEvent(), callback function is not a Lua
>> function.");
>> #endif // LUA_VERSION_NUM < 502
>>
>> I have never seen this error with 5.1 and am not sure what the purpose
>> of it is. Given that it doesn't even run for Lua 5.2, I completely
>> disabled this check and everything appears to be working as expected.
>>
>
> It's there for backwards compatibility so that programs run as expected in
> 5.1, but in 5.2 things are a little different. See below.
>
>
>>
>> Is there any reason for this check (especially given that it behaves
>> differently for lua 5.1 and 5.2) and is it possible to remove/disable
>> it?
>>
>
> In < 5.2 wxLua used the globals as the environment for the callback function
> to give a uniform state. This was how it was before I took over wxLua and
> though it wasn't strictly necessary I didn't see any reason to change it.
>
> In 5.2 setfenv() function was removed and the environment for a function is
> set by the _ENV table which should be the first upvalue for the function. I
> believe that this is automatic so the 5.2 behavior should be more expected,
> but I haven't rigorously tested what happens with callbacks in modules or
> even if you swap out the _ENV before setting the callback.
>
> http://stackoverflow.com/questions/14290527/recreating-setfenv-in-lua-5-2
>
> --------------------------------
>
> Is there any way to detect when the twoface DLL is being used so that the
> code can take the 5.2 path? Or maybe compile wxLua for 5.2 and use woface to
> treat 5.1 as 5.2 instead of the other way around.
>
>
> Regards,
> John
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On Fri, Jul 19, 2013 at 3:34 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I tried to compile the current trunk on Windows using mingw and ran
> into a compilation error:
>
> ...wxLua/modules/wxbind/src/wxcore_bind.cpp: In member function
> 'virtual bool wxLuaBinding_wxcore::RegisterBinding(const
> wxLuaState&)':
> ...wxlua/wxLua/modules/wxbind/src/wxcore_bind.cpp:7495:46: error:
> 'wxEVT_COMMAND_DIRPICKER_CHANGED' was not declared in this scope
> ...wxLua/modules/wxbind/src/wxcore_bind.cpp:7496:46: error:
> 'wxEVT_COMMAND_FILEPICKER_CHANGED' was not declared in this scope
>
> This follows a warning about re-definition:
>
> ...wxLua/modules/wxbind/src/wxcore_bind.cpp:73:0: warning:
> "wxEVT_COMMAND_DIRPICKER_CHANGED" redefined [enabled by default]
> ...include/wx-2.9/wx/filepicker.h:418:0: note: this is the location of
> the previous definition
> ...wxLua/modules/wxbind/src/wxcore_bind.cpp:74:0: warning:
> "wxEVT_COMMAND_FILEPICKER_CHANGED" redefined [enabled by default]
> ...include/wx-2.9/wx/filepicker.h:417:0: note: this is the location of
> the previous definition
>
> The issue seems to be caused by this #if in
> modules/wxbind/src/wxcore_bind.cpp:
>
> #if defined(__MINGW32__) || defined(__GNUWIN32__)
> // FIX: "internal compiler error: output_operand: invalid
> expression as operand"
>
> I'm not sure if the comment still applies, but I removed this #if (and
> another one around line 7488 in the same file) and compiled without
> any errors/issues.
>
>
When you say remove the #if you mean just the #if statement or all of the
code in the #if statement. As you can tell that is a strange hack for that
compiler and I wish I documented the version.
> Can you please take a look at this and check if this #if is still
> needed? It's seems like you can safely remove it. Thank you.
>
>
> I'm using the latest wxwidgets (2.9.5 release candidate) and gcc 4.6.2.
>
>
What gcc are you using? MingW as per these directions or something else and
from where and why?
http://wxlua.sourceforge.net/docs/install.html#C2.4
http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/
The mingw-get-inst-20120426<http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/>is
gcc 4.7.0 and I do believe that that #if is needed for that compiler.
Regards,
 John

On Fri, Jul 19, 2013 at 7:54 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I've been looking into using twoface ABI mapper
> (http://corsix.github.io/twoface/) to run ZeroBrane Studio on top of
> Lua 5.2 without recompiling wxlua and luasocket (both are compiled for
> Lua 5.1). For those not familiar with it, it allows to run Lua 5.2
> engine with modules compiled for Lua 5.1 without any changes to those
> modules. In my case, I use it with ZBS that is compiled for Lua 5.1
> and can make it run with Lua 5.2 by replacing lua51.dll with a
> different one (and adding lua52.dll).
>
>
Interesting, but that means that they're emulating the removed functions
and I wonder what their setfenv() does.
> I have been able to run it with wxlua, but I ended up patching wxlua
> in one place. For some reason when I ran it originally, I was getting
> "wxLua: wxEvtHandler::Connect() in wxLuaEventCallback::OnEvent(),
> callback function is not a Lua function." messages in more or less
> random places. This error comes from an event handler check in
> wxlcallb.cpp and it appears to be only active for Lua 5.1:
>
> #if LUA_VERSION_NUM < 502
> // lua_setfenv() is not in Lua 5.2 nor can you set an env for
> a function anymore
> wxlState.GetGlobals();
> if (wxlState.lua_SetFenv(-2) != 0)
> #endif // LUA_VERSION_NUM < 502
> {
> // Don't track the wxEvent since we don't own it and tracking
> it
> // causes clashes in the object registry table since many can
> be
> // created and deleted and the mem address is resused by C++.
> wxlState.wxluaT_PushUserDataType(event, event_wxl_type, false);
> wxlState.LuaPCall(1, 0); // one input no returns
> }
> #if LUA_VERSION_NUM < 502
> else
> wxlState.wxlua_Error("wxLua: wxEvtHandler::Connect() in
> wxLuaEventCallback::OnEvent(), callback function is not a Lua
> function.");
> #endif // LUA_VERSION_NUM < 502
>
> I have never seen this error with 5.1 and am not sure what the purpose
> of it is. Given that it doesn't even run for Lua 5.2, I completely
> disabled this check and everything appears to be working as expected.
>
>
It's there for backwards compatibility so that programs run as expected in
5.1, but in 5.2 things are a little different. See below.
> Is there any reason for this check (especially given that it behaves
> differently for lua 5.1 and 5.2) and is it possible to remove/disable
> it?
>
>
In < 5.2 wxLua used the globals as the environment for the callback
function to give a uniform state. This was how it was before I took over
wxLua and though it wasn't strictly necessary I didn't see any reason to
change it.
In 5.2 setfenv() function was removed and the environment for a function is
set by the _ENV table which should be the first upvalue for the function. I
believe that this is automatic so the 5.2 behavior should be more expected,
but I haven't rigorously tested what happens with callbacks in modules or
even if you swap out the _ENV before setting the callback.
http://stackoverflow.com/questions/14290527/recreating-setfenv-in-lua-5-2
--------------------------------
Is there any way to detect when the twoface DLL is being used so that the
code can take the 5.2 path? Or maybe compile wxLua for 5.2 and use woface
to treat 5.1 as 5.2 instead of the other way around.
Regards,
 John

Hi John,
I've been looking into using twoface ABI mapper
(http://corsix.github.io/twoface/) to run ZeroBrane Studio on top of
Lua 5.2 without recompiling wxlua and luasocket (both are compiled for
Lua 5.1). For those not familiar with it, it allows to run Lua 5.2
engine with modules compiled for Lua 5.1 without any changes to those
modules. In my case, I use it with ZBS that is compiled for Lua 5.1
and can make it run with Lua 5.2 by replacing lua51.dll with a
different one (and adding lua52.dll).
I have been able to run it with wxlua, but I ended up patching wxlua
in one place. For some reason when I ran it originally, I was getting
"wxLua: wxEvtHandler::Connect() in wxLuaEventCallback::OnEvent(),
callback function is not a Lua function." messages in more or less
random places. This error comes from an event handler check in
wxlcallb.cpp and it appears to be only active for Lua 5.1:
#if LUA_VERSION_NUM < 502
 // lua_setfenv() is not in Lua 5.2 nor can you set an env for
a function anymore
 wxlState.GetGlobals();
 if (wxlState.lua_SetFenv(-2) != 0)
#endif // LUA_VERSION_NUM < 502
 {
 // Don't track the wxEvent since we don't own it and tracking it
 // causes clashes in the object registry table since many can be
 // created and deleted and the mem address is resused by C++.
 wxlState.wxluaT_PushUserDataType(event, event_wxl_type, false);
 wxlState.LuaPCall(1, 0); // one input no returns
 }
#if LUA_VERSION_NUM < 502
 else
 wxlState.wxlua_Error("wxLua: wxEvtHandler::Connect() in
wxLuaEventCallback::OnEvent(), callback function is not a Lua
function.");
#endif // LUA_VERSION_NUM < 502
I have never seen this error with 5.1 and am not sure what the purpose
of it is. Given that it doesn't even run for Lua 5.2, I completely
disabled this check and everything appears to be working as expected.
Is there any reason for this check (especially given that it behaves
differently for lua 5.1 and 5.2) and is it possible to remove/disable
it?
Paul.

Hi John,
I tried to compile the current trunk on Windows using mingw and ran
into a compilation error:
...wxLua/modules/wxbind/src/wxcore_bind.cpp: In member function
'virtual bool wxLuaBinding_wxcore::RegisterBinding(const
wxLuaState&)':
...wxlua/wxLua/modules/wxbind/src/wxcore_bind.cpp:7495:46: error:
'wxEVT_COMMAND_DIRPICKER_CHANGED' was not declared in this scope
...wxLua/modules/wxbind/src/wxcore_bind.cpp:7496:46: error:
'wxEVT_COMMAND_FILEPICKER_CHANGED' was not declared in this scope
This follows a warning about re-definition:
...wxLua/modules/wxbind/src/wxcore_bind.cpp:73:0: warning:
"wxEVT_COMMAND_DIRPICKER_CHANGED" redefined [enabled by default]
...include/wx-2.9/wx/filepicker.h:418:0: note: this is the location of
the previous definition
...wxLua/modules/wxbind/src/wxcore_bind.cpp:74:0: warning:
"wxEVT_COMMAND_FILEPICKER_CHANGED" redefined [enabled by default]
...include/wx-2.9/wx/filepicker.h:417:0: note: this is the location of
the previous definition
The issue seems to be caused by this #if in modules/wxbind/src/wxcore_bind.cpp:
#if defined(__MINGW32__) || defined(__GNUWIN32__)
 // FIX: "internal compiler error: output_operand: invalid
expression as operand"
I'm not sure if the comment still applies, but I removed this #if (and
another one around line 7488 in the same file) and compiled without
any errors/issues.
Can you please take a look at this and check if this #if is still
needed? It's seems like you can safely remove it. Thank you.
I'm using the latest wxwidgets (2.9.5 release candidate) and gcc 4.6.2.
Paul.

Hi,
i respond to my self thanks to the solution given in the wxWidgets forum.
http://forums.wxwidgets.org/viewtopic.php?f=27&t=37637
The solution is to use the wxST_NO_AUTORESIZE flag described here; http://docs.wxwidgets.org/stable/wx_wxstatictext.html
Regards.
Javi
----- Mensaje original -----
> De: Javier Mr <jav...@ym...>
> Para: "wxl...@li..." <wxl...@li...>
> CC: 
> Enviado: Lunes 1 de julio de 2013 14:56
> Asunto: [wxlua-users] wxStaticText alignment reset on text update
> 
> Hi,
> 
> i'm not an expert with wxLua neither with wxWidgets. I think that what 
> i'm trying to do is quite simple but i can't get it to work. I have a 
> simple user interface with a label, the label is inside a horizontal sizer, I 
> want the text to be centered in the label, for accomplish i have done:
> 
>   local panel = wx.wxPanel(parent, wx.wxID_ANY);
> 
>   local label = wx.wxStaticText(panel, wx.wxID_ANY, "---", 
> wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxALIGN_CENTER);
> 
>   label:SetForegroundColour(wx.wxColour("RED"));
>   local labelFont = label:GetFont();
>   labelFont:SetPointSize(15);
>   labelFont:SetWeight(wx.wxFONTWEIGHT_BOLD);
>   label:SetFont(labelFont);
>   
>   local vSizer = wx.wxBoxSizer(wx.wxVERTICAL);
>   local hSizer1 = wx.wxBoxSizer(wx.wxHORIZONTAL);
>     
>   hSizer1:Add(label, 1, wx.wxEXPAND + wx.wxTOP + wx.wxBOTTOM + wx.wxRIGHT + 
> wx.wxLEFT);
>   
>   vSizer:Add(hSizer1, 5, wx.wxEXPAND +wx.wxCENTER, 5);
>   
>   panel:SetSizer(vSizer);
> 
> 
> This gets the job done (in the snippet of code i also se the text to red color 
> and change the font). However the text needs to change dynamically and when i 
> try to change is with:
> 
>   label:SetForegroundColour(wx.wxColour("GREEN"));
>   label:SetLabel("+++");
>   label:SetWindowStyleFlag(wx.wxALIGN_CENTER);
>   label:Refresh();
> 
> The label defaults to left align ( First I tried without the SetWindowStyleFlag 
> call, but that didn't work). What i'm doing wrong?, why is the align 
> reset to left?
> Wich one is the correct way to update the text value without changing the label 
> aligment?
> 
> TIA.
> 
> Best regards.
> Javi.
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
> 

Hi,
i'm not an expert with wxLua neither with wxWidgets. I think that what i'm trying to do is quite simple but i can't get it to work. I have a simple user interface with a label, the label is inside a horizontal sizer, I want the text to be centered in the label, for accomplish i have done:
  local panel = wx.wxPanel(parent, wx.wxID_ANY);
  local label = wx.wxStaticText(panel, wx.wxID_ANY, "---", wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxALIGN_CENTER);
  label:SetForegroundColour(wx.wxColour("RED"));
  local labelFont = label:GetFont();
  labelFont:SetPointSize(15);
  labelFont:SetWeight(wx.wxFONTWEIGHT_BOLD);
  label:SetFont(labelFont);
  
  local vSizer = wx.wxBoxSizer(wx.wxVERTICAL);
  local hSizer1 = wx.wxBoxSizer(wx.wxHORIZONTAL);
    
  hSizer1:Add(label, 1, wx.wxEXPAND + wx.wxTOP + wx.wxBOTTOM + wx.wxRIGHT + wx.wxLEFT);
  
  vSizer:Add(hSizer1, 5, wx.wxEXPAND +wx.wxCENTER, 5);
  
  panel:SetSizer(vSizer);
This gets the job done (in the snippet of code i also se the text to red color and change the font). However the text needs to change dynamically and when i try to change is with:
  label:SetForegroundColour(wx.wxColour("GREEN"));
  label:SetLabel("+++");
  label:SetWindowStyleFlag(wx.wxALIGN_CENTER);
  label:Refresh();
The label defaults to left align ( First I tried without the SetWindowStyleFlag call, but that didn't work). What i'm doing wrong?, why is the align reset to left?
Wich one is the correct way to update the text value without changing the label aligment?
TIA.
Best regards.
Javi.