wxlua-users — wxLua list for users and developers

Re: [wxlua-users] [ wxlua-Patches-1622013 ] editor

[Francesco M. <f18...@ya...>]

Hi John,
     if you've applied these patches, maybe the relative SF tracker 
entries should be closed?

Francesco


John Labenski ha scritto:
> I've been working on these two patches.  I have integrated the first
> one and tweaked it a little, but I wonder why you wanted to combine
> the "Start Debug" and "Continue" debugger menu items. In some sense
> they are very similar, but I really think they ought to be separate so
> that you know to first start the debugging process and then either
> step forward or continue. I think it would be confusing to have the
> same menu item do two things.
> 
> 
> For the second patch, I found some bugs. There's two menu item
> separators in the edit menu, the function find combo shows "HHHHHH" if
> there's no text, and the find/replace dialog gives an error when
> clicked.
> 
> lua: Error while running chunk
> wxLua: Expected a number for parameter 2, but got 'nil'.
> stack traceback:
>         [C]: in function 'wxDialog'
>         editor2.wx.lua:1591: in function 'GetFindReplaceDialog'
>         editor2.wx.lua:1742: in function 'Show'
>         editor2.wx.lua:1752: in function <editor2.wx.lua:1750>
> 
> Anyway, it adds a lot of great features and hopefully I'll be able to
> get it done and committed tonight.
> 
> Thanks,
>     John Labenski
> 
> 
> 
> 
> On 12/25/06, SourceForge.net <no...@so...> wrote:
>> Patches item #1622013, was opened at 2006-12-25 10:17
>> Message generated for change (Tracker Item Submitted) made by Item Submitter
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=745326&aid=1622013&group_id=140042
>>
>> Please note that this message will contain a full copy of the comment thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: None
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Andre Arpin (andrearpin)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: editor
>>
>> Initial Comment:
>> These changes are to make the editor easier to use to improve it. This should make the editor friendlier.
>>
>> Fix a numbers of minor problems.
>> Added comment toggling
>> Added sort
>> Added a more complete find/replace
>> Added some folding
>>
>> There is a number of issues that still have to addressed.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Francesco M. <f18...@ya...>]

Doug Currie ha scritto:
> On Wednesday, January 31, 2007 Francesco Montorsi wrote: 
> 
>> Also, just out of curiosity, how much the size of the final EXE increases using
>> RUNTIME_LIBS==static?
> 
> WinXP MinGW wxMSW-2.8.0 (static) wxLua-2.8.0.0 (static)
> 
> wxluasudoku.exe     7.90 MB (8,290,489 bytes)
> 
> wxluasudoku_upx.exe 2.18 MB (2,291,385 bytes)
sorry - are you sure you're using RUNTIME_LIBS==static  and not rather 
the SHARED=0 option?

It seems strange you're using RUNTIME_LIBS==static with wxLua also 
because I haven't added support for it yet :D

Francesco

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Francesco M. <f18...@ya...>]

Hakki Dogusan ha scritto:
> Hi,
> 
> Hakki Dogusan yazmış:
>> Hi,
>>
>> Francesco Montorsi yazmış:
>> [snip]
>>> Also, just out of curiosity, how much the size of the final EXE increases using 
>>> RUNTIME_LIBS==static?
>>>
>>> Francesco
>>>
>>>
>> (WinXP, MinGW, wx-2.80)
>>
>> I'm using wxLua module like that; it is ~10Mb (with upx ~3Mb)
>>
>>
> 
> Stupid Hakki! You're using RUNTIME_LIBS=dynamic for wx.
> Do not confuse it with using static wx libs!
:D

Francesco

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Doug C. <dou...@gm...>]

On Wednesday, January 31, 2007 Francesco Montorsi wrote: 

> Also, just out of curiosity, how much the size of the final EXE increases using
> RUNTIME_LIBS==static?

WinXP MinGW wxMSW-2.8.0 (static) wxLua-2.8.0.0 (static)

wxluasudoku.exe     7.90 MB (8,290,489 bytes)

wxluasudoku_upx.exe 2.18 MB (2,291,385 bytes)

e

--
Doug Currie
Londonderry, NH, USA

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Hakki D. <dog...@tr...>]

Hi,

Hakki Dogusan yazmış:
> Hi,
> 
> Francesco Montorsi yazmış:
> [snip]
>> Also, just out of curiosity, how much the size of the final EXE increases using 
>> RUNTIME_LIBS==static?
>>
>> Francesco
>>
>>
> 
> (WinXP, MinGW, wx-2.80)
> 
> I'm using wxLua module like that; it is ~10Mb (with upx ~3Mb)
> 
> 

Stupid Hakki! You're using RUNTIME_LIBS=dynamic for wx.
Do not confuse it with using static wx libs!

:-[



--
Regards,
Hakki Dogusan

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi yazmış:
[snip]
> 
> Also, just out of curiosity, how much the size of the final EXE increases using 
> RUNTIME_LIBS==static?
> 
> Francesco
> 
> 

(WinXP, MinGW, wx-2.80)

I'm using wxLua module like that; it is ~10Mb (with upx ~3Mb)



--
Regards,
Hakki Dogusan

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Ryan P. <rpu...@gm...>]

On 1/31/07, Francesco Montorsi <f18...@ya...> wrote:
> well, it won't be difficult to add it but I wonder how much it is useful... do
> you do that to create an app with fewer dynamic dependencies?

Yes. This is always a debate, but Microsoft has ruined how easy it
used to be to distribute the run-time in VC8.0 with there manifest
tool. I hate it and I won't do it. My thought is if it is easy to
implement then give the users the choice, right?

Why would you have a static library and not make it completely
dependency free? It just doesn't seem intuitive to me. If I want
.dll's then of coarse I wouldn't mind the run-time dll, but otherwise
I just like to make things simpler.

> Also, just out of curiosity, how much the size of the final EXE increases using
> RUNTIME_LIBS==static?

I haven't got a definite answer for that. I don't think by very much.
plus the size of the exe doesn't matter too much because generally
using a large library like wxWidgets it make the executable larger
anyways. You give up size for convenience. ;-)
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Francesco M. <f18...@ya...>]

Ryan Pusztai ha scritto:
> Is there a possibility that you could add the RUNTIME_LIBS variable to
> the bakefile scripts like wxWidgets has? The reason is because I
> compile wxWidgets with the run-time statically linked and you don't
> have an option for that. This would be set to the default of what it
> is currently.
> 
> What do you think?
well, it won't be difficult to add it but I wonder how much it is useful... do 
you do that to create an app with fewer dynamic dependencies?

Also, just out of curiosity, how much the size of the final EXE increases using 
RUNTIME_LIBS==static?

Francesco

Re: [wxlua-users] Serial Port module for wxLua

[John L. <jla...@gm...>]

On 1/31/07, Ryan Pusztai <rpu...@gm...> wrote:
>
> I am going to attempt to create a binding for wxCTB's wxSerialPort and
> I have a question about the .i file.
>
> If the header file has items in it, but the only thing I care about is
> an enumeration do I delete everything other than the items I care
> about?

You need only put the things you want accessible to lua in the .i
file. In fact, if a class has a base class you need only wrap the
topmost class and add the useful base class functions to it. It would
only make sense to wrap the base class if two or more classes use it.

Hope this helps,
    John Labenski

Re: [wxlua-users] Serial Port module for wxLua

[Ryan P. <rpu...@gm...>]

On 1/30/07, John Labenski <jla...@gm...> wrote:
> On 1/30/07, Ryan Pusztai <rpu...@gm...> wrote:
> > On 1/30/07, John Labenski <jla...@gm...> wrote:
> > > wxCTB is the only one I know of. I have read on wx-users that it works
> > > and people like it if that helps. I have not seen it myself, but I
> > > assume that wrapping it should be pretty straight forward.
> >
> > How do I bind wxCTB:wxSerialPort() to wxLua? I am new to wxLua and I
> > feel like that would be beyond my skills right now. I use wxWidgets on
> > a daily basis, but Lua I am just starting with. Any article/how-to or
> > help would be greatly appreciated. I think I only want the serial port
> > class not the whole library. Should I make it a wxLua module? Is that
> > equivalent to binding?
>
> The bindings are easy to make, read this
> http://wxlua.sourceforge.net/documentation.php
> http://wxlua.sourceforge.net/docs/binding.html
>
> Take a look at any of the bindings
> http://wxlua.cvs.sourceforge.net/wxlua/wxLua/bindings/wxwidgets/appframe.i?view=markup
>
> Copy the header you want to bind to *.i and then just clean them up a
> little. See also the apps/wxluacan sample which has it's own bindings.
>
> Generate the bindings using genwxbind.lua, using your "rules" file
> (just copy an existing one and change the names of a few things) and
> then create the output CPP files. See genwxbind.bat for the command
> line syntax of genwxbind.lua.
>
> Once you've got your binding files, compile them with your project (or
> make your own lib) and link to it. I suppose that you could make these
> modules loadable by 'require', but that would take some doing.

I am going to attempt to create a binding for wxCTB's wxSerialPort and
I have a question about the .i file.

If the header file has items in it, but the only thing I care about is
an enumeration do I delete everything other than the items I care
about?
-- 
Regards,
Ryan
RJP Computing

[wxlua-users] Adding the equivalent to RUNTIME_LIBS to bakefiles

[Ryan P. <rpu...@gm...>]

Is there a possibility that you could add the RUNTIME_LIBS variable to
the bakefile scripts like wxWidgets has? The reason is because I
compile wxWidgets with the run-time statically linked and you don't
have an option for that. This would be set to the default of what it
is currently.

What do you think?
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Make "print()" print to the console instead of a messagebox

[John L. <jla...@gm...>]

On 1/31/07, Ryan Pusztai <rpu...@gm...> wrote:
> Is there a way to make wxLua "print()" to the console instead of a
> MessageBox? I see you do this when running from wxLuaEdit.

If you use wxLua to run a lua program directly you can use the command
line switch -c to pop up a console window. When you run or debug a
program in wxLua.exe IDE you're actually running a new process so the
code to start the new wxLua process has to be changed. This is fixed
in cvs, you can download the new copy of editor.wx.lua and run it as
$ wxLua editor.wx.lua

http://wxlua.cvs.sourceforge.net/wxlua/wxLua/samples/editor.wx.lua?view=log

Regards,
    John Labenski

[wxlua-users] Make "print()" print to the console instead of a messagebox

[Ryan P. <rpu...@gm...>]

Is there a way to make wxLua "print()" to the console instead of a
MessageBox? I see you do this when running from wxLuaEdit.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Serial Port module for wxLua

[John L. <jla...@gm...>]

On 1/30/07, Ryan Pusztai <rpu...@gm...> wrote:
> On 1/30/07, John Labenski <jla...@gm...> wrote:
> > wxCTB is the only one I know of. I have read on wx-users that it works
> > and people like it if that helps. I have not seen it myself, but I
> > assume that wrapping it should be pretty straight forward.
>
> How do I bind wxCTB:wxSerialPort() to wxLua? I am new to wxLua and I
> feel like that would be beyond my skills right now. I use wxWidgets on
> a daily basis, but Lua I am just starting with. Any article/how-to or
> help would be greatly appreciated. I think I only want the serial port
> class not the whole library. Should I make it a wxLua module? Is that
> equivalent to binding?

The bindings are easy to make, read this
http://wxlua.sourceforge.net/documentation.php
http://wxlua.sourceforge.net/docs/binding.html

Take a look at any of the bindings
http://wxlua.cvs.sourceforge.net/wxlua/wxLua/bindings/wxwidgets/appframe.i?view=markup

Copy the header you want to bind to *.i and then just clean them up a
little. See also the apps/wxluacan sample which has it's own bindings.

Generate the bindings using genwxbind.lua, using your "rules" file
(just copy an existing one and change the names of a few things) and
then create the output CPP files. See genwxbind.bat for the command
line syntax of genwxbind.lua.

Once you've got your binding files, compile them with your project (or
make your own lib) and link to it. I suppose that you could make these
modules loadable by 'require', but that would take some doing.

Regards,
    John Labenski

Re: [wxlua-users] Serial Port module for wxLua

[Ryan P. <rpu...@gm...>]

On 1/30/07, Hakki Dogusan <dog...@tr...> wrote:
> (I saw your message in lua list, but didn't reply
> it with "use wxCTB" :) )

Yeah I have not got any responses to that. I saw a really nice serial
port library as part of LuaX, but it doesn't use the "require()"
mechanism and I don't know how to change that. Or even if it would be
a complete rewrite.

> I used/using it in automation software.
> It works very well!

Good to know. Thanks.

> But I don't have a lua binding for it :(

Too bad because I have know idea how to do that.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Serial Port module for wxLua

[Ryan P. <rpu...@gm...>]

On 1/30/07, John Labenski <jla...@gm...> wrote:
> wxCTB is the only one I know of. I have read on wx-users that it works
> and people like it if that helps. I have not seen it myself, but I
> assume that wrapping it should be pretty straight forward.

How do I bind wxCTB:wxSerialPort() to wxLua? I am new to wxLua and I
feel like that would be beyond my skills right now. I use wxWidgets on
a daily basis, but Lua I am just starting with. Any article/how-to or
help would be greatly appreciated. I think I only want the serial port
class not the whole library. Should I make it a wxLua module? Is that
equivalent to binding?
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] I have some questions...

[Patrick E. <sha...@ho...>]

>From: "John Labenski" <jla...@gm...>
>Reply-To: wxl...@li...
>To: wxl...@li...
>Subject: Re: [wxlua-users] I have some questions...
>Date: Tue, 30 Jan 2007 13:41:28 -0500
>
>On 1/30/07, Patrick Elliott <sha...@ho...> wrote:
> > I am using a client to play MUDs which recently went withLua as its 
>"main"
> > scripting system. This works nicely, but has a fatal flaw imho, which is
> > shared by all other script systems in this context. wxLua would correct 
>this
> > flaw, by adding the capacity to develop new GUI elements within the 
>context
>
>This would be easy to do with wxLua.
>
> > So, I would like to be able to convince the developer to switch to wxLua
> > instead. But, several questions need answering:
> >
> > 1. Threading. This already causes some issues. While coprocedures can be
> > used and suspended/resumed to "fake" true threading, no additional 
>threading
> > systems are available. One reason being to avoid the script going out of
> > sync with the data incoming to it. You don't want some complex process
> > handling something to deal with line 50, while the client is displaying 
>line
> > 120, and a third script is altering the contents of line 114, which 
>must,
> > after that, be redisplayed in the correct order... The fear is obvious. 
>How
> > do events effect the situtation in cases where the script system and 
>client
> > are in the same thread space, and anything the script does may "suspend" 
>the
> > client until its finished?
>
>If they're in the same thread then only one of them is active, events
>will only be sent when your functions are idle. You cannot have "while
>1 do ... end" since you don't allow the event loop to run unless you
>call wxApp::Pending() and Dispatch(). I believe there was some
>messages on wxlua-users about this too?
>
Yep. This is already a known issue. Causes all sorts of hassle when trying 
to do something like the attempt I made to use an API call in vbscript (the 
client supports like 7-8 options for script engines, though Lua is likely to 
eventually become the "only" one, do to its features and portability) to 
open an http port, load a page, then display the current ranking from that 
page for the MUD. Hung the client, mostly due to dialup, for like a minute 
and a half waiting for the function to return the data. lol

Nah, 90% of the time the scripts are idle, with the client handling 
everything. Its only when timed, triggered or macro events, generated by the 
client, happen and those either call a script function, or execute 
"immediate" code, that the scripts become active, for the duration of what 
ever that script does. This is usually fractions of a second. The issue here 
is a bit more complicated though, since the clients means of making these 
calls is to have its "own" events simply perform a call to the script. No 
GUI elements fire events that are handled by the script system at the 
moment. So if, for example, you had an input box, the client would do this:

Show box.
Handle "OK" button event.
Check to see if master script or any "plugin" contains OnTextBox or 
OnPluginTextBox function.
Call any functions that do exist for that.

Plugins in this context are XML files containing triggers (fire on incoming 
text), aliases (fire on user input), timers and any script related to them, 
all in a self contained instance. Each plugin can use a different language, 
and more to the point, each one that uses script in that language produces a 
seperate instance of the script engine, so that all variables and functions 
in them exist independently, without naming conflicts or other issues.

What this means is that if you could have plugins for several things, such 
as:

a) main script, for those things hard to do in a plugin - written with 
PhpScript
b) tracking how many items you found in a quest, sent to the main output - 
written with VBScript
c) icon bar for spells - written with wxLua
d) window for tracking player health graphically - written with wxLua
e) window for displaying graphics, using callbacks for the MXP protocol - 
written with wxLua
f) text window for chat, with a seperate chat input - written with wxLua
g) some plugin to keep track of potions you can make - written with Python
h) something else - written with Perlscript
etc.

All of them with entirely independent variable and script spaces, of which 
c, d, e, f and *maybe* g are have some sort of GUI elements that can or do 
generate events that their "specific" scripts need to handle.

> > Put simply, none of us have a real clear understanding of just how the 
>heck
> > the event system works, or what effect that could have on the client.
>
>The event system is the GUI main loop. All GUI calls MUST be made in
>the main thread since that's what the underlying system, MSW, GTK,
>OSX, supports. You can create wxThreads in wxLua (untested, but there
>shouldn't be any reason why they wouldn't work) and use wxPostEvent to
>queue events back to the main thread where you can then call GUI
>functions.
>
Umm. English please? lol But seriously, MFC handles all that internally 
itself, passing the needed events to the correct places, at least *when* 
everything you are using is MFC. Its slightly less certain what happens when 
you attach someone else's window to the main GUI frame of an application 
that didn't create it, even if the window is made by a script system which 
is running "in" that applications event system. Where trying to shoehorn 
things in place here I think, and most applications avoid it, like IE does, 
by having all objects create "through its own" instancing system. wxLua as a 
stand alone environment doesn't have a main window until you make one. 
Things like Photoshop, which you meantion, have fairly specific interfaces 
"designed" to deal with these things, and its not clear how they work, since 
having the interface code to make a plugin isn't the same thing as having 
the code *for* the interface itself.

The thread I found in using it with Photoshop is also talking about MACs, 
which tend to have different event sink systems than Windows too, so not 
sure how it would translate.

> > 3. Now, this is the one that is the cause of some of the angst about the
> > above issues. How does wxLua deal with cases where *it* isn't the 
>initial
> > GUI host? Put simply, the client has its own windows. There is a 
>function
> > added a while back, so that other applications could get better data on 
>the
> > client windows position, etc., called "GetFrame". This returns a handle 
>to
> > the main window of the client. This means that, in theory, making a new
> > window is as simple as telling the frame creation function in wxLua to 
>use
> > "that" handle as the parent, not NULL. However, this could potentially 
>have
> > an impact on just how events get handled.
>
>See wx-users mailing list for messages about using wxWidgets as a
>plugin for photoshop. I believe there is code about how to do this,
>perhaps on the Wiki? I know it can be done in C++ and there's no
>reason why it wouldn't work with the lua bindings since wxLua is
>really only translating from lua to C to wxWidgets C++ and back. We
>may have to wrap the HNDWND however or just treat it as a void*
>pointer.
>
Not possible to use "void*" or the like. That is **only** allowed if its the 
first window in the thread space. Creating one that way will briefly give 
you a frame, then immediately crash both the client and the script engine. I 
tried it with Python way back before we had a "getframe" function in the 
client, and well before I know how to use the windows API functions to do a 
FindWindow... lol I gave up on trying for over a year, and went looking for 
other options instead. Later the GetFrame function was added, but by then I 
was wandering down a dead end search for a COM bridge to get events 
working... At the time I had even less of a clue how events worked than I do 
now, and given that I am still confused about it... lol

> > ...
>
>See the photoshop plugin discussions.
>
Things like this don't give me much confidence:

"but the interesting thing for me is now whether Photoshop has installed
its own handlers which would be delivered with events even using this
implementation, or whether it still needs the old WNE style version.
Then I'd have to install some low level handlers presumably at the app
level which then would deliver synthesized events to the plug-in
connection point. the alternative being that we'd run the old style WNE
event loop for these situations, which would mean that I would not need
any additional code."

And that is ignoring how most of the thread is about MAC, not Windows...

>The way I see it is, you'll create your own plugin module, a DLL I
>suppose with a bit of C++ code as described in the photoshop plugin
>wx-users/wx-dev message threads, create a wxLuaState (eg. a lua_State)
>and then throw code at it.
>
That is what he is doing now, with Lua. The issue becomes, what happens if 
that code then creates a window, sticks some buttons on it, then expects the 
events from those things it owns, but the client itself is the parent of 
(again, you can't create two master windows in the same application, and as 
a dll, Lua and wxLua exist as "part" of the client application, as far as 
the OS is concerned. Most implimentations are "not" going to be using the 
clients window as its main, or, as with things like IE, limit the feature 
you can create, by "requiring" that you use the clients version of 
CreateObject, or what ever, to make the new items, as well as having "it" 
handle the "connect" function and the events. Its not entirely clear what 
happens if you want the client to host the objects made by the script, but 
the script to instance them and call the connect functions for the objects 
events, instead of letting the client do it, or alternatively, as is most 
common in all the examples usually do, have the script do "all" of the event 
handling and GUI creation.

We are looking at a mixed bag here. I personally think that it should work 
anyway. At worst, it might be necessary to do something like:

main_events {
  Is this my event?
    handle_event
  else
    a = 0
    loop
      script = scriptlist[a]
      pass_event_to (script)
      a = a + 1
    until scriptlist[a] = NULL
}

In other words, it may be necessary to override the MFC main event loop and 
add code to send each active script engine the events that the client 
recieves, but would normally go, "What the #$#$? I don't own that!"

>Some simple examples of the C++ side are in
>wxLua/modules/luamodule
>wxLua/apps/wxluafreeze
>wxLua/apps/wxlua
>
I'll take a look, but I suspect these will use the same "wxLua creates all 
the GUI elements" types. I don't find a wide dearth of examples that deal 
with *unusual* cases with... almost any language. lol

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline

Re: [wxlua-users] Serial Port module for wxLua

[Hakki D. <dog...@tr...>]

Hi,

Ryan Pusztai wrote:
> Hi,
> 
> Is there a serial port lua module or serial port support for wxLua?
> 
> I am in need of such a library and can't seem to find anything other
> then the wxCTB library and that is much bigger than I want or need.
> Any help would be greatly appreciated.


(I saw your message in lua list, but didn't reply
it with "use wxCTB" :) )


I used/using it in automation software.
It works very well!

But I don't have a lua binding for it :(


--
Regards,
Hakki Dogusan

Re: [wxlua-users] Serial Port module for wxLua

[John L. <jla...@gm...>]

On 1/30/07, Ryan Pusztai <rpu...@gm...> wrote:
> Hi,
>
> Is there a serial port lua module or serial port support for wxLua?
>
> I am in need of such a library and can't seem to find anything other
> then the wxCTB library and that is much bigger than I want or need.
> Any help would be greatly appreciated.

wxCTB is the only one I know of. I have read on wx-users that it works
and people like it if that helps. I have not seen it myself, but I
assume that wrapping it should be pretty straight forward.

Regards,
    John Labenski

[wxlua-users] Serial Port module for wxLua

[Ryan P. <rpu...@gm...>]

Hi,

Is there a serial port lua module or serial port support for wxLua?

I am in need of such a library and can't seem to find anything other
then the wxCTB library and that is much bigger than I want or need.
Any help would be greatly appreciated.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] I have some questions...

[John L. <jla...@gm...>]

On 1/30/07, Patrick Elliott <sha...@ho...> wrote:
> I am using a client to play MUDs which recently went withLua as its "main"
> scripting system. This works nicely, but has a fatal flaw imho, which is
> shared by all other script systems in this context. wxLua would correct this
> flaw, by adding the capacity to develop new GUI elements within the context

This would be easy to do with wxLua.

> So, I would like to be able to convince the developer to switch to wxLua
> instead. But, several questions need answering:
>
> 1. Threading. This already causes some issues. While coprocedures can be
> used and suspended/resumed to "fake" true threading, no additional threading
> systems are available. One reason being to avoid the script going out of
> sync with the data incoming to it. You don't want some complex process
> handling something to deal with line 50, while the client is displaying line
> 120, and a third script is altering the contents of line 114, which must,
> after that, be redisplayed in the correct order... The fear is obvious. How
> do events effect the situtation in cases where the script system and client
> are in the same thread space, and anything the script does may "suspend" the
> client until its finished?

If they're in the same thread then only one of them is active, events
will only be sent when your functions are idle. You cannot have "while
1 do ... end" since you don't allow the event loop to run unless you
call wxApp::Pending() and Dispatch(). I believe there was some
messages on wxlua-users about this too?

> Put simply, none of us have a real clear understanding of just how the heck
> the event system works, or what effect that could have on the client.

The event system is the GUI main loop. All GUI calls MUST be made in
the main thread since that's what the underlying system, MSW, GTK,
OSX, supports. You can create wxThreads in wxLua (untested, but there
shouldn't be any reason why they wouldn't work) and use wxPostEvent to
queue events back to the main thread where you can then call GUI
functions.

You can also "fake" threads using EVT_IDLE, these are idle events that
are sent when the event queue is emptied and you can use
wxIdleEvent::RequestMore (IIRC) to keep it going.

> 2. We don't have a clue how the event system works at all in this context.
> Does the client, which is written in MFC, need to have some adjustment made
> for the event generators and sinks to even work within wxLua? If so, how? If
> not, then why not?

Please see #1 and #3.

> 3. Now, this is the one that is the cause of some of the angst about the
> above issues. How does wxLua deal with cases where *it* isn't the initial
> GUI host? Put simply, the client has its own windows. There is a function
> added a while back, so that other applications could get better data on the
> client windows position, etc., called "GetFrame". This returns a handle to
> the main window of the client. This means that, in theory, making a new
> window is as simple as telling the frame creation function in wxLua to use
> "that" handle as the parent, not NULL. However, this could potentially have
> an impact on just how events get handled.

See wx-users mailing list for messages about using wxWidgets as a
plugin for photoshop. I believe there is code about how to do this,
perhaps on the Wiki? I know it can be done in C++ and there's no
reason why it wouldn't work with the lua bindings since wxLua is
really only translating from lua to C to wxWidgets C++ and back. We
may have to wrap the HNDWND however or just treat it as a void*
pointer.

> Now, my impression is that the new frame and its objects should become
> children of the main client window. This should mean that MFC will
> automatically pass any messages for those objects "to" the correct child
> window, and that event generated by those should correctly call the
> functions in wxLua that they have been "connected" to. But I admit complete
> ignorance on the subject with respect to *if* this is true, not to mention
> how to fix the problem if its not. Obviously, most examples that the wxlua
> system comes with "assume" that the client has no window, and that wxLua
> itself will create the master window. This doesn't lend any information one
> way or the other as to what the result will be in any case this isn't the
> way things are set up.

See the photoshop plugin discussions.

> Thanks for any help you can provide on these issues. The client I use is
> quite good, but needing to rely on "external" extensions to provide new GUI
> elements adds a level of complication that makes it unlikely for most people
> to even try developing such extensions. It adds a what is a nasty learning
> curve and huge cost to doing so, or, in the case of free compilers, which
> lack the additional tools to make development easy, it creates an "insane"
> learning curve, which 99% of the clients users are never going to over come,
> and which even most of those that already have the skill and tools, don't
> want to waste on it. wxLua could potentially solve a huge problem if it will
> work as I hope it does in such an implimentation.

The way I see it is, you'll create your own plugin module, a DLL I
suppose with a bit of C++ code as described in the photoshop plugin
wx-users/wx-dev message threads, create a wxLuaState (eg. a lua_State)
and then throw code at it.

Some simple examples of the C++ side are in
wxLua/modules/luamodule
wxLua/apps/wxluafreeze
wxLua/apps/wxlua

Hope this helps,
    John Labenski

[wxlua-users] I have some questions...

[Patrick E. <sha...@ho...>]

I am using a client to play MUDs which recently went withLua as its "main" 
scripting system. This works nicely, but has a fatal flaw imho, which is 
shared by all other script systems in this context. wxLua would correct this 
flaw, by adding the capacity to develop new GUI elements within the context 
of the client's own functions and windows. Right now, we have to do some 
screwy things, like creating a dummy window in the client, which cannot be 
undocked and dropped some place else, then using that to send output (with 
color), or using an internal notepad, which has the same issue. We can't add 
buttons, icons, graphical maps, etc., without implimenting them as ActiveX 
applications, to be instanced and loaded from in the script, and which must 
be specially linked to the client's own entry points to talk to it. The 
script system can call these entry points without the hassle, since they are 
automatically exposed to it *and*, more to the point, people don't need to 
learn C++, MFC, etc., etc., and buy some complicated compiler to do anything 
using scripting. At least, until you need those GUI features...

So, I would like to be able to convince the developer to switch to wxLua 
instead. But, several questions need answering:

1. Threading. This already causes some issues. While coprocedures can be 
used and suspended/resumed to "fake" true threading, no additional threading 
systems are available. One reason being to avoid the script going out of 
sync with the data incoming to it. You don't want some complex process 
handling something to deal with line 50, while the client is displaying line 
120, and a third script is altering the contents of line 114, which must, 
after that, be redisplayed in the correct order... The fear is obvious. How 
do events effect the situtation in cases where the script system and client 
are in the same thread space, and anything the script does may "suspend" the 
client until its finished?

Put simply, none of us have a real clear understanding of just how the heck 
the event system works, or what effect that could have on the client.

2. We don't have a clue how the event system works at all in this context. 
Does the client, which is written in MFC, need to have some adjustment made 
for the event generators and sinks to even work within wxLua? If so, how? If 
not, then why not?

3. Now, this is the one that is the cause of some of the angst about the 
above issues. How does wxLua deal with cases where *it* isn't the initial 
GUI host? Put simply, the client has its own windows. There is a function 
added a while back, so that other applications could get better data on the 
client windows position, etc., called "GetFrame". This returns a handle to 
the main window of the client. This means that, in theory, making a new 
window is as simple as telling the frame creation function in wxLua to use 
"that" handle as the parent, not NULL. However, this could potentially have 
an impact on just how events get handled.

Now, my impression is that the new frame and its objects should become 
children of the main client window. This should mean that MFC will 
automatically pass any messages for those objects "to" the correct child 
window, and that event generated by those should correctly call the 
functions in wxLua that they have been "connected" to. But I admit complete 
ignorance on the subject with respect to *if* this is true, not to mention 
how to fix the problem if its not. Obviously, most examples that the wxlua 
system comes with "assume" that the client has no window, and that wxLua 
itself will create the master window. This doesn't lend any information one 
way or the other as to what the result will be in any case this isn't the 
way things are set up.

Thanks for any help you can provide on these issues. The client I use is 
quite good, but needing to rely on "external" extensions to provide new GUI 
elements adds a level of complication that makes it unlikely for most people 
to even try developing such extensions. It adds a what is a nasty learning 
curve and huge cost to doing so, or, in the case of free compilers, which 
lack the additional tools to make development easy, it creates an "insane" 
learning curve, which 99% of the clients users are never going to over come, 
and which even most of those that already have the skill and tools, don't 
want to waste on it. wxLua could potentially solve a huge problem if it will 
work as I hope it does in such an implimentation.

_________________________________________________________________
Valentine’s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping 
http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline

Re: [wxlua-users] Embeding a binary file into an executable

[Ryan P. <rpu...@gm...>]

On 1/22/07, John Labenski <jla...@gm...> wrote:
>
> On 1/22/07, Ryan Pusztai <rpu...@gm...> wrote:
> > Does anybody know how to embed a binary file into an executable and then
> > extract it back out at runtime. I want to create a utility that can make
> > application self contained and if they require dlls or external files
> they
> > can be packed into the .exe file. Then at run-time it extracts them and
> then
> > the main application can run and use the files.
>
> I am also a big fan of single executable programs, but unfortunately
> what you ask for is difficult if not impossible.


There is a good implimentation of this in AutoIT v3. I would love to have
the same functionality in wxLua.

1) You can embed raw data into wxLua as a table of integers for each
> byte. We would probably need to add functions catered to how to use
> the data for a specific purposes.


Ah, ok. I saw bin2c.lua in the 'utils' directory i will look into how you
did that.

2) Embedding dlls is not so easy I think. I have toyed with the idea
> of using the wxWidgets wxZipFileSystem to zip up data and then use it.
> I do not know if you can do this with dlls though. If this were
> possible wxLuaFreeze could take advantage of that, but unfortunately I
> do not have time these days to look into it.


Yeah I am really looking for something really simplistic, that just appends
to the executable then extract to the specified location.

You may want to do a web search for how to embed dlls in C++ and how
> use them to see if it's even possible or reasonably easy to do. If so,
> we can go from there to see just what it would take to add the same
> functionality in wxLua.


Ok. Will do and I will let you know what I find out.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Unicode Problem and the Copyright symbol ((c))

[Ryan P. <rpu...@gm...>]

On 1/22/07, John Labenski <jla...@gm...> wrote:
>
> On 1/22/07, Ryan Pusztai <rpu...@gm...> wrote:
> > When I wxluafreeze a script that has a Copyright symbol (c), the
> application
> > quits right away with no error or anything. I am using it in an about
> box
> > and I am just wondering if it has to do with Unicode at all. I am using
> the
> > prebuilt wxluafreeze from the 'bin' directory and I have built it myself
> as
> > well. I get the same result. Also, it works great when ran with "wxLua"
> and
> > not frozen. For now I am just changing the (c) to (c).
> >
> > Any thoughts would be greatly appreciated.
>
> I have tried this in the minimal.cpp sample using MS VS2005 and (c)
> does work in the about dialog there. Why it doesn't work in wxLua is
> probably because of the wx2lua and lua2wx string conversion functions
> in modules/wxlua/include/wxlstate.h.
>
> This has been discussed before, but with no resolution. The problem is
> that people make suggestions for changes to make it work for them, but
> would break things for other people. I do not understand much about
> unicode or even UTF8 strings other than a cursory knowledge so I
> cannot help much. I presented a summary of the different suggestions
> on the mailing list, but nobody seemed to know definitely what was
> right.
>
> see "wx2lua & Unicode was Re: [wxlua-users] Problem in using Turkish
> in wxLua scripts"
>
> I think we have two competing needs, unicode for international
> languages and UTF8 for ??? Can the two be mixed? I dunno.
>
>
Thanks for the response, I will read the posts and see if I can offer any
insight. I am not an expert either, I just know the silent fail really is
bad and spent quite a bit of time looking for the error. Maybe just that can
be improved?
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] Unicode Problem and the Copyright symbol ((c))

[John L. <jla...@gm...>]

I don't have time to read this now, but this was just posted on the
wx-users mailing list in response to this message "Using Chinese (not
i18n)".

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?8:msp:94195:hljgalnnllihfkjijnlh

Maybe the programs wxluafreeze, wxlua, etc need to have command line
switches to allow you to specify ASCII, UTF8, etc. I think the problem
with the copyright symbol is that the UTF8 converter gags on it, but
happily passes though 7-bit ASCII.  For most purposes the converter is
transparent, but it does the wrong thing for 8-bit ASCII.

Regards,
    John Labenski


On 1/22/07, John Labenski <jla...@gm...> wrote:
> On 1/22/07, Ryan Pusztai <rpu...@gm...> wrote:
> > When I wxluafreeze a script that has a Copyright symbol (c), the application
> > quits right away with no error or anything. I am using it in an about box
> > and I am just wondering if it has to do with Unicode at all. I am using the
> > prebuilt wxluafreeze from the 'bin' directory and I have built it myself as
> > well. I get the same result. Also, it works great when ran with "wxLua" and
> > not frozen. For now I am just changing the (c) to (c).
> >
> > Any thoughts would be greatly appreciated.
>
> I have tried this in the minimal.cpp sample using MS VS2005 and (c)
> does work in the about dialog there. Why it doesn't work in wxLua is
> probably because of the wx2lua and lua2wx string conversion functions
> in modules/wxlua/include/wxlstate.h.
>
> This has been discussed before, but with no resolution. The problem is
> that people make suggestions for changes to make it work for them, but
> would break things for other people. I do not understand much about
> unicode or even UTF8 strings other than a cursory knowledge so I
> cannot help much. I presented a summary of the different suggestions
> on the mailing list, but nobody seemed to know definitely what was
> right.
>
> see "wx2lua & Unicode was Re: [wxlua-users] Problem in using Turkish
> in wxLua scripts"
>
> I think we have two competing needs, unicode for international
> languages and UTF8 for ??? Can the two be mixed? I dunno.
>
> Regards,
>     John Labenski
>