wxlua-users Mailing List for wxLua

On Fri, Oct 23, 2015 at 3:55 AM, Victor Bombi <so...@te...> wrote:

> try it without "\n" (all in a line)
>

I'm guessing that's a limitation of the number of columns Scintilla
handles, it looks like one bit less than a 2-byte short. Maybe the last
bit/values are used for some metadata. I don't see any recent Scintilla
documentation about limitations, but I wouldn't be surprised.

Here's some older limitations:
http://scintilla-interest.narkive.com/Ciq49QLW/long-lines

Regards,
    John




> ----- Original Message -----
> *From:* John Labenski <jla...@gm...>
> *To:* wxl...@li...
> *Sent:* Friday, October 23, 2015 5:42 AM
> *Subject:* Re: [wxlua-users] wxStyledTextCtrl:AppendText
>
>
> On Sun, Oct 18, 2015 at 2:27 PM, Victor Bombi <so...@te...>
> wrote:
>
>> Hi,
>>
>> 32*1024 - 7 is the maximum string len that is displayed in
>> wxStyledTextCtrl
>> with AppendText.
>> I have not seen anywhere information related.
>> Is this information in any place?
>> Is there any way to get a longer display length?
>>
>>
> Maybe there is an invalid utf8 char at that position that truncates it?
>
> I added this line to the end of the samples/editor.wx.lua LoadFile
> function and got all 40000 lines and even tried a larger value without a
> problem.
>
> function LoadFile(filePath, editor, file_must_exist)
> ...
>     editor:AppendText(string.rep("1234567890\n", 40000))
>     return editor
> end
>
> Regards,
>     John
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
>
> ------------------------------
>
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
>

Hi,

even if this is not directly wxLua related: i can give a confirmation 
for that "long/size_t" problem on 64bit windows8+ and that today this 
thread gave me the correct kick in the right direction for another 
project. Thank you very much!

Since some days i had a problem getting a lua/ffi 64bit project running 
on windows8. It seems that some ASLR magic is done since windows8 which 
causes some problems. I tried "unsigned long long" before but it didn't 
work here. I am not sure if there was another problem too, i have to 
check that again.

Bye
Björn



On 23.10.2015 09:56, Laurent Renoux wrote:
> Thx for your answer.
>
> Sorry for my approximation, I only work under Windows. I use Visual 2012
> where size_t is defined as follow
>
> #ifndef_SIZE_T_DEFINED
>
> #ifdef_WIN64
>
> typedefunsigned__int64size_t;
>
> #else
>
> typedef_W64 unsignedintsize_t;
>
> #endif
>
> #define_SIZE_T_DEFINED
>
> #endif
>
> In x64
>
> sizeof(long) = 4
>
> sizeof(long long) = 8
>
> sizeof(size_t) = 8
>
> In x86
>
> sizeof(long) = 4
>
> sizeof(long long) = 4
>
> sizeof(size_t) = 4
>
> Regards,
>
> Laurent
>
> *De :*John Labenski [mailto:jla...@gm...]
> *Envoyé :* vendredi 23 octobre 2015 05:13
> *À :* wxl...@li...
> *Objet :* Re: [wxlua-users] wxLua x64
>
> On Thu, Sep 3, 2015 at 8:03 AM, Laurent Renoux <lr...@iv...
> <mailto:lr...@iv...>> wrote:
>
>     Hi John,
>
>     At first, i would like to tell you how big is your works : thanks
>     for all.
>
>     I use wxLua with wxWidget 3.0.2 since 1 year on x86 and x64
>     platforms on Windows 7 with no matter. Since I have jumped on
>     Windows 10, wxLua crash on x64. Same dll, same code. I think, I have
>     found the problem.
>
>     In file wxlstate.cpp In function
>
>     void* LUACALL wxluaT_getuserdatatype(lua_State* L, intstack_idx,
>     intwxl_type)
>
>                   long int o = (long int)wxlua_touserdata(L, stack_idx,
>     false);
>
>     should be changed in
>
>                   size_t o = (size_t)wxlua_touserdata(L, stack_idx, false);
>
>     on Windows platforms to avoid original pointer to be truncated in 32
>     bits. Why it doesn’t crash since 1 year on Win7, I really don’t
>     know, probably I’m a lucky man and memory management has changed on
>     Win10 !
>
> Humm, my understanding was that both long and size_t are 4 bytes on a
> 32-bit architecture and 8 bytes on a 64-bit architecture, but I see now
> that there are claims that Visual Studio kept long at 4 bytes on x64. It
> seems like there is no guarantees about size_t other than that it will
> be unsigned in the C++ standard.
>
> Can you please print sizeof(long) and sizeof(size_t) and let me know
> what compiler you use?
>
>
> I should use an uintptr_t, but older Visual Studio versions don't have
> inttypes.h so I've changed it to 'unsigned long long' so it'll work
> everywhere. The change is committed to svn.
>
> Regards,
>
>       John
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On Fri, Oct 23, 2015 at 3:56 AM, Laurent Renoux <lr...@iv...>
wrote:

> Thx for your answer.
>
>
>
> Sorry for my approximation, I only work under Windows. I use Visual 2012
> where size_t is defined as follow
>
>
Ok, thanks. Let me know if 'unsigned long long' doesn't work. It's
suboptimal for 32-bit, but I think compiler compatibility trumps that.
Someday I'll move the code into the 21st century.

Thanks,
    John



>
>
>
>
> #ifndef _SIZE_T_DEFINED
>
> #ifdef  _WIN64
>
> typedef unsigned __int64    size_t;
>
> #else
>
> typedef _W64 unsigned int   size_t;
>
> #endif
>
> #define _SIZE_T_DEFINED
>
> #endif
>
>
>
> In x64
>
>
>
> sizeof(long) = 4
>
> sizeof(long long) = 8
>
> sizeof(size_t) = 8
>
>
>
> In x86
>
>
>
> sizeof(long) = 4
>
> sizeof(long long) = 4
>
> sizeof(size_t) = 4
>
>
>
>
>
> Regards,
>
>
>
> Laurent
>
>
>
>
>
> *De :* John Labenski [mailto:jla...@gm...]
> *Envoyé :* vendredi 23 octobre 2015 05:13
> *À :* wxl...@li...
> *Objet :* Re: [wxlua-users] wxLua x64
>
>
>
> On Thu, Sep 3, 2015 at 8:03 AM, Laurent Renoux <lr...@iv...>
> wrote:
>
> Hi John,
>
>
>
> At first, i would like to tell you how big is your works : thanks for all.
>
>
>
> I use wxLua with wxWidget 3.0.2 since 1 year on x86 and x64 platforms on
> Windows 7 with no matter. Since I have jumped on Windows 10, wxLua crash on
> x64. Same dll, same code. I think, I have found the problem.
>
>
>
> In file wxlstate.cpp In function
>
>
>
> void* LUACALL wxluaT_getuserdatatype(lua_State* L, int stack_idx, int
> wxl_type)
>
>
>
>              long int o = (long int)wxlua_touserdata(L, stack_idx, false);
>
>
>
> should be changed in
>
>
>
>              size_t o = (size_t)wxlua_touserdata(L, stack_idx, false);
>
>
>
> on Windows platforms to avoid original pointer to be truncated in 32 bits.
> Why it doesn’t crash since 1 year on Win7, I really don’t know, probably
> I’m a lucky man and memory management has changed on Win10 !
>
>
>
>
>
> Humm, my understanding was that both long and size_t are 4 bytes on a
> 32-bit architecture and 8 bytes on a 64-bit architecture, but I see now
> that there are claims that Visual Studio kept long at 4 bytes on x64. It
> seems like there is no guarantees about size_t other than that it will be
> unsigned in the C++ standard.
>
> Can you please print sizeof(long) and sizeof(size_t) and let me know what
> compiler you use?
>
>
> I should use an uintptr_t, but older Visual Studio versions don't have
> inttypes.h so I've changed it to 'unsigned long long' so it'll work
> everywhere. The change is committed to svn.
>
> Regards,
>
>      John
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
>

Thx for your answer.

Sorry for my approximation, I only work under Windows. I use Visual 2012 where size_t is defined as follow


#ifndef _SIZE_T_DEFINED
#ifdef  _WIN64
typedef unsigned __int64    size_t;
#else
typedef _W64 unsigned int   size_t;
#endif
#define _SIZE_T_DEFINED
#endif

In x64

sizeof(long) = 4
sizeof(long long) = 8
sizeof(size_t) = 8

In x86

sizeof(long) = 4
sizeof(long long) = 4
sizeof(size_t) = 4


Regards,

Laurent


De : John Labenski [mailto:jla...@gm...]
Envoyé : vendredi 23 octobre 2015 05:13
À : wxl...@li...
Objet : Re: [wxlua-users] wxLua x64

On Thu, Sep 3, 2015 at 8:03 AM, Laurent Renoux <lr...@iv...<mailto:lr...@iv...>> wrote:
Hi John,

At first, i would like to tell you how big is your works : thanks for all.

I use wxLua with wxWidget 3.0.2 since 1 year on x86 and x64 platforms on Windows 7 with no matter. Since I have jumped on Windows 10, wxLua crash on x64. Same dll, same code. I think, I have found the problem.

In file wxlstate.cpp In function

void* LUACALL wxluaT_getuserdatatype(lua_State* L, int stack_idx, int wxl_type)

             long int o = (long int)wxlua_touserdata(L, stack_idx, false);

should be changed in

             size_t o = (size_t)wxlua_touserdata(L, stack_idx, false);

on Windows platforms to avoid original pointer to be truncated in 32 bits. Why it doesn’t crash since 1 year on Win7, I really don’t know, probably I’m a lucky man and memory management has changed on Win10 !


Humm, my understanding was that both long and size_t are 4 bytes on a 32-bit architecture and 8 bytes on a 64-bit architecture, but I see now that there are claims that Visual Studio kept long at 4 bytes on x64. It seems like there is no guarantees about size_t other than that it will be unsigned in the C++ standard.
Can you please print sizeof(long) and sizeof(size_t) and let me know what compiler you use?

I should use an uintptr_t, but older Visual Studio versions don't have inttypes.h so I've changed it to 'unsigned long long' so it'll work everywhere. The change is committed to svn.
Regards,
     John

try it without "\n" (all in a line)
  ----- Original Message ----- 
  From: John Labenski 
  To: wxl...@li... 
  Sent: Friday, October 23, 2015 5:42 AM
  Subject: Re: [wxlua-users] wxStyledTextCtrl:AppendText




  On Sun, Oct 18, 2015 at 2:27 PM, Victor Bombi <so...@te...> wrote:

    Hi,

    32*1024 - 7 is the maximum string len that is displayed in wxStyledTextCtrl
    with AppendText.
    I have not seen anywhere information related.
    Is this information in any place?
    Is there any way to get a longer display length?




  Maybe there is an invalid utf8 char at that position that truncates it?


  I added this line to the end of the samples/editor.wx.lua LoadFile function and got all 40000 lines and even tried a larger value without a problem.

  function LoadFile(filePath, editor, file_must_exist)
  ...

      editor:AppendText(string.rep("1234567890\n", 40000))
      return editor
  end


  Regards,

      John




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


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



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


  _______________________________________________
  wxlua-users mailing list
  wxl...@li...
  https://lists.sourceforge.net/lists/listinfo/wxlua-users

Hi John,

> These will require a C++ wxLuaApp class that have its virtual functions called by wxWidgets and then forward them to an overridden Lua function if supplied, similar to how printing is implemented.

That's a good lead; I'll take a look at that.

> Sorry, I don't know. To be sure, these are basically drag and drop handlers?

Mostly, except probably MacAppReopen. I think they all have the same
structure with C++ callback function called, which then calls a Lua
function (if setup).

Paul.

On Thu, Oct 22, 2015 at 8:52 PM, John Labenski <jla...@gm...> wrote:
> On Wed, Oct 21, 2015 at 5:52 PM, Paul K <pau...@ya...> wrote:
>>
>> Hi John,
>>
>> > I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp
>> > methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would
>> > appreciate any update on when you may have chance to add them.
>>
>> Do you have any update on Mac* methods or any suggestion on how these
>> can be added? Maybe you can do one or two of them and I'll use it as
>> an example to complete the other methods? It would be good to also add
>> MacPrintFile and MacOpenURL as my product now supports file printing
>> as well.
>>
>
> These will require a C++ wxLuaApp class that have its virtual functions
> called by wxWidgets and then forward them to an overridden Lua function if
> supplied, similar to how printing is implemented.
>
> The problem is that I don't have a Mac so I can't test and this not the sort
> of code that can be blindly written with any hope of it working or even
> compiling.
>
>>
>> If you are not available to work on this, can you recommend someone
>> who can do this or at least to provide some initial implementation.
>> Thank you.
>>
>
> Sorry, I don't know. To be sure, these are basically drag and drop handlers?
>
> Regards,
>     John
>
>
>> On Sat, Feb 21, 2015 at 2:52 PM, Paul K <pau...@ya...> wrote:
>> > Hi John,
>> >
>> > I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp
>> > methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would
>> > appreciate any update on when you may have chance to add them.
>> >
>> > If you don't have time at all to work on these and other methods, could
>> > you
>> > give me a hint on how these can be added or maybe implement one of them
>> > and
>> > I'll take care of the others? I can add existing methods (like those
>> > needed
>> > for wxSTC or wxTreeCtrl), but it seems like these methods need some sort
>> > of
>> > callback and I don't know how to provide that.
>> >
>> > Paul.
>> >
>> >
>> > On Thu, Oct 30, 2014 at 11:01 AM, Paul K <pau...@ya...> wrote:
>> >>
>> >> Hi John,
>> >>
>> >> >> > I'm looking for a way to provide MacNewFile, MacOpenFiles, and
>> >> >> > MacReopenApp methods
>> >> >> > (http://docs.wxwidgets.org/trunk/classwx_app.html), but can't
>> >> >> > figure
>> >> >> > out how to do this in wxlua and don't see this in any of the
>> >> >> > examples.
>> >> >>
>> >> >> Can these methods be used with the current version of wxlua or do
>> >> >> they
>> >> >> need to be added first?
>> >> >
>> >> > They need to be added, it should be doable.
>> >>
>> >> Any plans to add these methods?
>> >>
>> >> Also, I have a short list of various methods that exist in wxwidgets
>> >> 3.x, but are missing from wxlua API:
>> >>
>> >> wxTopLevelWindow needs EnableFullScreenView
>> >> wxTreeCtrl needs GetFocusedItem, SetFocusedItem, ClearFocusedItem
>> >> wxSTC needs ScrollRange, ScrollCaret, SetFontQuality, AddStyledText
>> >> wxAuiTabArt needs SetColour and SetActiveColour
>> >>
>> >> If it makes things easier for you, I can probably submit the initial
>> >> patch that adds these methods, but AddStyledText seems to be disabled
>> >> explicitly, so I'd appreciate if you could check why that's the case.
>> >> Thank you.
>> >>
>> >> Also, it's possible to provide my own wxAuiTabArt provider?
>> >>
>> >> Paul.
>> >
>> >
>
>

On Wed, Oct 21, 2015 at 5:52 PM, Paul K <pau...@ya...> wrote:

> Hi John,
>
> > I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp
> methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would
> appreciate any update on when you may have chance to add them.
>
> Do you have any update on Mac* methods or any suggestion on how these
> can be added? Maybe you can do one or two of them and I'll use it as
> an example to complete the other methods? It would be good to also add
> MacPrintFile and MacOpenURL as my product now supports file printing
> as well.
>
>
These will require a C++ wxLuaApp class that have its virtual functions
called by wxWidgets and then forward them to an overridden Lua function if
supplied, similar to how printing is implemented.

The problem is that I don't have a Mac so I can't test and this not the
sort of code that can be blindly written with any hope of it working or
even compiling.


> If you are not available to work on this, can you recommend someone
> who can do this or at least to provide some initial implementation.
> Thank you.
>
>
Sorry, I don't know. To be sure, these are basically drag and drop handlers?

Regards,
    John


On Sat, Feb 21, 2015 at 2:52 PM, Paul K <pau...@ya...> wrote:
> > Hi John,
> >
> > I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp
> > methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would
> > appreciate any update on when you may have chance to add them.
> >
> > If you don't have time at all to work on these and other methods, could
> you
> > give me a hint on how these can be added or maybe implement one of them
> and
> > I'll take care of the others? I can add existing methods (like those
> needed
> > for wxSTC or wxTreeCtrl), but it seems like these methods need some sort
> of
> > callback and I don't know how to provide that.
> >
> > Paul.
> >
> >
> > On Thu, Oct 30, 2014 at 11:01 AM, Paul K <pau...@ya...> wrote:
> >>
> >> Hi John,
> >>
> >> >> > I'm looking for a way to provide MacNewFile, MacOpenFiles, and
> >> >> > MacReopenApp methods
> >> >> > (http://docs.wxwidgets.org/trunk/classwx_app.html), but can't
> figure
> >> >> > out how to do this in wxlua and don't see this in any of the
> >> >> > examples.
> >> >>
> >> >> Can these methods be used with the current version of wxlua or do
> they
> >> >> need to be added first?
> >> >
> >> > They need to be added, it should be doable.
> >>
> >> Any plans to add these methods?
> >>
> >> Also, I have a short list of various methods that exist in wxwidgets
> >> 3.x, but are missing from wxlua API:
> >>
> >> wxTopLevelWindow needs EnableFullScreenView
> >> wxTreeCtrl needs GetFocusedItem, SetFocusedItem, ClearFocusedItem
> >> wxSTC needs ScrollRange, ScrollCaret, SetFontQuality, AddStyledText
> >> wxAuiTabArt needs SetColour and SetActiveColour
> >>
> >> If it makes things easier for you, I can probably submit the initial
> >> patch that adds these methods, but AddStyledText seems to be disabled
> >> explicitly, so I'd appreciate if you could check why that's the case.
> >> Thank you.
> >>
> >> Also, it's possible to provide my own wxAuiTabArt provider?
> >>
> >> Paul.
> >
> >
>

On Sun, Oct 18, 2015 at 2:27 PM, Victor Bombi <so...@te...> wrote:

> Hi,
>
> 32*1024 - 7 is the maximum string len that is displayed in wxStyledTextCtrl
> with AppendText.
> I have not seen anywhere information related.
> Is this information in any place?
> Is there any way to get a longer display length?
>
>
Maybe there is an invalid utf8 char at that position that truncates it?

I added this line to the end of the samples/editor.wx.lua LoadFile function
and got all 40000 lines and even tried a larger value without a problem.

function LoadFile(filePath, editor, file_must_exist)
...
    editor:AppendText(string.rep("1234567890\n", 40000))
    return editor
end

Regards,
    John

On Fri, Oct 16, 2015 at 7:42 AM, Z.H. <zo...@ye...> wrote:

> Hi all, wxLua reference manual says the following classes are unavailable:
>
> wxCSConv                     X           Lua uses ANSI 8-bit strings
> wxEncodingConverter     X           Lua uses ANSI 8-bit strings
> wxMBConv                     X           Lua uses ANSI 8-bit strings
> wxMBConvFile             X           Lua uses ANSI 8-bit strings
> wxMBConvUTF16             X           Lua uses ANSI 8-bit strings
> wxMBConvUTF32             X           Lua uses ANSI 8-bit strings
> wxMBConvUTF7             X           Lua uses ANSI 8-bit strings
> wxMBConvUTF8             X           Lua uses ANSI 8-bit strings
>
> As far as I know, wxLua unicode build will treat all lua strings as utf-8
> strings when converting them from/to wxString's.
> It works fine in most situations. But some applications need to read and
> write files with other encodings
> (see for example the post by Victor Bombi :
> http://sourceforge.net/p/wxlua/mailman/message/33546327/ ).
> In this case, wxEncodingConverter and wxMBConv are neccessary.
>
> Is it possible for wxLua to implement the above classes?
>


The comments about only using ANSI 8-bit strings is slightly misleading in
that they do handle utf-8 as shown in the message you show, but any Lua
string functions will probably not work as expected. This is why I'm not
sure that they would be very useful.

Maybe there is a small subset of the functionality that would suffice for
you and what would that be?

Regards,
    John

On Thu, Sep 3, 2015 at 8:03 AM, Laurent Renoux <lr...@iv...>
wrote:

> Hi John,
>
>
>
> At first, i would like to tell you how big is your works : thanks for all.
>
>
>
> I use wxLua with wxWidget 3.0.2 since 1 year on x86 and x64 platforms on
> Windows 7 with no matter. Since I have jumped on Windows 10, wxLua crash on
> x64. Same dll, same code. I think, I have found the problem.
>
>
>
> In file wxlstate.cpp In function
>
>
>
> void* LUACALL wxluaT_getuserdatatype(lua_State* L, int stack_idx, int
> wxl_type)
>
>
>
>              long int o = (long int)wxlua_touserdata(L, stack_idx, false);
>
>
>
> should be changed in
>
>
>
>              size_t o = (size_t)wxlua_touserdata(L, stack_idx, false);
>
>
>
> on Windows platforms to avoid original pointer to be truncated in 32 bits.
> Why it doesn’t crash since 1 year on Win7, I really don’t know, probably
> I’m a lucky man and memory management has changed on Win10 !
>
>
>

Humm, my understanding was that both long and size_t are 4 bytes on a
32-bit architecture and 8 bytes on a 64-bit architecture, but I see now
that there are claims that Visual Studio kept long at 4 bytes on x64. It
seems like there is no guarantees about size_t other than that it will be
unsigned in the C++ standard.

Can you please print sizeof(long) and sizeof(size_t) and let me know what
compiler you use?

I should use an uintptr_t, but older Visual Studio versions don't have
inttypes.h so I've changed it to 'unsigned long long' so it'll work
everywhere. The change is committed to svn.

Regards,
     John

Hi John,

I noticed that wxlua fails to compile with the current wxwidgets as it
references GetKeysUnicode and SetKeysUnicode methods for
wxStyledTextCtrl, which have been removed in 3.1.

Both of the methods need to be marked as !%wxchkver_3_1_0 in
wxstc_stc.i and modules/wxbind/src/wxstc_bind.cpp needs to be
regenerated.

BTW, wxwidgets has been migrated to github, so the latest version is
here (https://github.com/wxWidgets/wxWidgets) and not in svn.

Paul.

Hi John,

> I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would appreciate any update on when you may have chance to add them.

Do you have any update on Mac* methods or any suggestion on how these
can be added? Maybe you can do one or two of them and I'll use it as
an example to complete the other methods? It would be good to also add
MacPrintFile and MacOpenURL as my product now supports file printing
as well.

If you are not available to work on this, can you recommend someone
who can do this or at least to provide some initial implementation.
Thank you.

Paul.

On Sat, Feb 21, 2015 at 2:52 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I'm still in need of having MacNewFile, MacOpenFiles, and MacReopenApp
> methods (http://docs.wxwidgets.org/trunk/classwx_app.html) and would
> appreciate any update on when you may have chance to add them.
>
> If you don't have time at all to work on these and other methods, could you
> give me a hint on how these can be added or maybe implement one of them and
> I'll take care of the others? I can add existing methods (like those needed
> for wxSTC or wxTreeCtrl), but it seems like these methods need some sort of
> callback and I don't know how to provide that.
>
> Paul.
>
>
> On Thu, Oct 30, 2014 at 11:01 AM, Paul K <pau...@ya...> wrote:
>>
>> Hi John,
>>
>> >> > I'm looking for a way to provide MacNewFile, MacOpenFiles, and
>> >> > MacReopenApp methods
>> >> > (http://docs.wxwidgets.org/trunk/classwx_app.html), but can't figure
>> >> > out how to do this in wxlua and don't see this in any of the
>> >> > examples.
>> >>
>> >> Can these methods be used with the current version of wxlua or do they
>> >> need to be added first?
>> >
>> > They need to be added, it should be doable.
>>
>> Any plans to add these methods?
>>
>> Also, I have a short list of various methods that exist in wxwidgets
>> 3.x, but are missing from wxlua API:
>>
>> wxTopLevelWindow needs EnableFullScreenView
>> wxTreeCtrl needs GetFocusedItem, SetFocusedItem, ClearFocusedItem
>> wxSTC needs ScrollRange, ScrollCaret, SetFontQuality, AddStyledText
>> wxAuiTabArt needs SetColour and SetActiveColour
>>
>> If it makes things easier for you, I can probably submit the initial
>> patch that adds these methods, but AddStyledText seems to be disabled
>> explicitly, so I'd appreciate if you could check why that's the case.
>> Thank you.
>>
>> Also, it's possible to provide my own wxAuiTabArt provider?
>>
>> Paul.
>
>

Hi,

32*1024 - 7 is the maximum string len that is displayed in wxStyledTextCtrl 
with AppendText.
I have not seen anywhere information related.
Is this information in any place?
Is there any way to get a longer display length?

Best
victor 

Hi all, wxLua reference manual says the following classes are unavailable:

wxCSConv 	                X 	  	Lua uses ANSI 8-bit strings 
wxEncodingConverter 	X 	  	Lua uses ANSI 8-bit strings 
wxMBConv 	                X 	  	Lua uses ANSI 8-bit strings
wxMBConvFile 	        X 	  	Lua uses ANSI 8-bit strings
wxMBConvUTF16 	        X 	  	Lua uses ANSI 8-bit strings
wxMBConvUTF32 	        X 	  	Lua uses ANSI 8-bit strings
wxMBConvUTF7 	        X 	  	Lua uses ANSI 8-bit strings
wxMBConvUTF8 	        X 	  	Lua uses ANSI 8-bit strings

As far as I know, wxLua unicode build will treat all lua strings as utf-8 strings when converting them from/to wxString's.
It works fine in most situations. But some applications need to read and write files with other encodings
(see for example the post by Victor Bombi :  http://sourceforge.net/p/wxlua/mailman/message/33546327/ ).
In this case, wxEncodingConverter and wxMBConv are neccessary.

Is it possible for wxLua to implement the above classes?

I was running on Windows 7, 32bit.
At 2015-10-16 13:11:30,"Paul K" <pau...@ya...> wrote:
>> Running program: cmd /k dir & exit
>> Pid is 6640
>> Process Ended
>> Can Read
>> And no further result. It's very strange.
>
>It is strange. It's as if the program is done, but nothing is
>"waiting" in the output to be read. Did you say you were running on
>Win10? Maybe it's a new "feature"?
>
>I'd try on some other Windows machine you may have access to...
>
>Paul.

> Running program: cmd /k dir & exit
> Pid is 6640
> Process Ended
> Can Read
> And no further result. It's very strange.

It is strange. It's as if the program is done, but nothing is
"waiting" in the output to be read. Did you say you were running on
Win10? Maybe it's a new "feature"?

I'd try on some other Windows machine you may have access to...

Paul.

What I get for that command is:

Running program: cmd /k dir & exit
Pid is 6640
Process Ended
Can Read

And no further result. It's very strange.

At 2015-10-15 10:13:53,"Paul K" <pau...@ya...> wrote:
>> The command "cmd /k dir & exit" did not work when I ran it from ZBS.
>
>What do you mean by "did not work"? This is what I get for that command:
>
>Running program: cmd /k dir & exit
>Pid is 18556
>Can Read
> Volume in drive D is FILES
> Volume Serial Number is 6AF1-AFBB
>...
>
>If I pass the wrong command, I get "Can Read" and then "No Output",
>which is what you'd expect.
>
>Paul.
>

> The command "cmd /k dir & exit" did not work when I ran it from ZBS.

What do you mean by "did not work"? This is what I get for that command:

Running program: cmd /k dir & exit
Pid is 18556
Can Read
 Volume in drive D is FILES
 Volume Serial Number is 6AF1-AFBB
...

If I pass the wrong command, I get "Can Read" and then "No Output",
which is what you'd expect.

Paul.

The command "cmd /k dir & exit" did not work when I ran it from ZBS.
At 2015-10-14 22:59:47,"Paul K" <pau...@ya...> wrote:
>> I download wxLua-2.8.12.3-Lua-5.2.2-MSW-Unicode.zip and wrote the following code for testing wxExecute function. But the results of "streamin:Read" function are always empty.
>>    local cmd = "cmd /k tree d: & exit"
>>    Output("Running program: " .. cmd .. "\n")
>
>I used a slightly different command ("cmd /k dir & exit"), but it
>worked just fine when I ran it from ZeroBrane Studio. Maybe try with a
>different wx.dll library?
>
>Paul.
>
>------------------------------------------------------------------------------
>_______________________________________________
>wxlua-users mailing list
>wxl...@li...
>https://lists.sourceforge.net/lists/listinfo/wxlua-users

> I download wxLua-2.8.12.3-Lua-5.2.2-MSW-Unicode.zip and wrote the following code for testing wxExecute function. But the results of "streamin:Read" function are always empty.
>    local cmd = "cmd /k tree d: & exit"
>    Output("Running program: " .. cmd .. "\n")

I used a slightly different command ("cmd /k dir & exit"), but it
worked just fine when I ran it from ZeroBrane Studio. Maybe try with a
different wx.dll library?

Paul.

I download wxLua-2.8.12.3-Lua-5.2.2-MSW-Unicode.zip and wrote the following code for testing wxExecute function. But the results of "streamin:Read" function are always empty.

I have tried the exec example contained in wxWidgets' source code. And I could see the redirected output with this command "cmd /k tree d: & exit".

If I replace the command "cmd /k tree d: & exit" with "attrib", I could get the desired result. What's the problem with the following code?

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


package.cpath = package.cpath..";./?.dll;./?.so;../lib/?.so;../lib/vc_dll/?.dll;"
require("wx")

frame = wx.wxFrame( wx.NULL, wx.wxID_ANY,"wxLua Demo", wx.wxDefaultPosition,
                    wx.wxSize(600,480), wx.wxDEFAULT_FRAME_STYLE )

console = wxstc.wxStyledTextCtrl(frame, wx.wxID_ANY)
console:Show(true)function Output(message)
    console:AppendText(message)
    console:GotoPos(console:GetLength())endlocal proc, streamin

function ReadIt(event)if streamin and streamin:CanRead()then
        Output("Can Read\n")local str = streamin:Read(4096)
        print(str)
        Output(str .."\n")else
        Output("No Output\n")endendlocal myTimer = wx.wxTimer(frame)
frame:Connect(wx.wxEVT_TIMER, ReadIt)function Execute() 
    proc = wx.wxProcess()
    proc:Redirect()
    proc:Connect(wx.wxEVT_END_PROCESS,function(event)
          myTimer:Stop();
          Output("Process Ended\n")
          ReadIt()
          proc =nilend)local cmd ="cmd /k tree d: & exit"
    Output("Running program: ".. cmd .."\n")local pid = wx.wxExecute(cmd, wx.wxEXEC_ASYNC, proc)
    Output("Pid is ".. pid .."\n")
    streamin = proc and proc:GetInputStream()
    myTimer:Start(500);end 

frame:Show(true)
Execute()
wx.wxGetApp():MainLoop()