wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] How to generate the bindings.

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

On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>=20
> I don''t understand how i need to generate the bindings.
> I see a genwxbind.bat, but it gives errors and nothing more.

What errors? See below about probably solving them.

>  From source.bkl, i get the idea there should be a whole lot of file in
> .../modules/wxbind/src.
> But even the nmake -f makefile.vc does not generate those files.
> So i think i have to do it myself.

See wxLua/apps/wxlua/src/wrap.lua also wrap.bat. These files are used
to generate the wrapper files. If you can call them from your cmake
file somehow you can just copy and use them. See also the
Makefile_import makefile and wxLua_wx26.dsp also in the apps/wxlua/src
dir.

Eventually we can just have the wrapper files pregenerated, but I
figured that until we get things sorted out, just generate them
locally.

Regards,
    John Labenski

[Wxlua-users] How to generate the bindings.

[klaas.holwerda <kho...@xs...>]

Hi John,

I don''t understand how i need to generate the bindings.

I see a genwxbind.bat, but it gives errors and nothing more.

 From source.bkl, i get the idea there should be a whole lot of file in 
.../modules/wxbind/src.
But even the nmake -f makefile.vc does not generate those files.
So i think i have to do it myself.

How to get them there or why are they there?
And how do i generate the bindings?

I want to automatically generate them with Cmake where that is possible.

Thanks,

Klaas

[Wxlua-users] wxbind/include/wxbind.h

[klaas.holwerda <kho...@xs...>]

included from  in internal.cpp

Where is  it?


BTW i read the thread on binding with you and Francesco, i think i get it.
There is no bindings library yet.
It is all application specific.  ( like in apps/wxlua ).
Still a bit confused what is in the bakefiles on this wxbind sources.

Klaas

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

-- In the absence of an answer, I've made a workround:
-- Use Show() and Enable() instead of ShowModal() and EndModal().
-- This suggests the problem might be in the inbuilt wxWidgets or wxLua code for ShowModal().
--
-- I've removed the FilePane in this example, showing that the existing ShowModal() doesn't let the dialog respond to the first click if the file dialog didn't immediately preceed the ShowModal for my own dialog(). In other words, the second tool button does what the first one did before.
-- The first button now uses the workround, and the means of closing the dialog now work as they should, at first attempt, with the dialog having the same effect that ShowModal() would have it was working right.

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

local FS=wx.wxDEFAULT_FRAME_STYLE-wx.wxMAXIMIZE_BOX-wx.wxRESIZE_BORDER
FRAME=wx.wxFrame(wx.wxNull,-1,"",wx.wxDefaultPosition,wx.wxSize(432,310),FS)    -- Main GUI frame, supports menus and all good stuffs.

PANEL=wx.wxPanel(FRAME,-1)                                                      -- Dialog-like control/surface in a Frame.

BANK=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))              -- Make two identical test dialogs.
CNFG=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))

IDB=0

BMP_I=wx.wxBitmapFromFile("Bitmaps/new.bmp",wx.wxBITMAP_TYPE_BMP)
BMP_O=wx.wxBitmapFromFile("Bitmaps/open.bmp",wx.wxBITMAP_TYPE_BMP)
TBAR=wx.wxToolBar(PANEL,ID_TOOLBAR,wx.wxPoint(-1,14),wx.wxSize(-1,-1),wx.wxTB_FLAT)
TBAR:AddTool(201,BMP_I,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
TBAR:AddTool(202,BMP_O,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
TBAR:Realize()  TBAR:Move(-1,-2)  TBAR:SetSize(440,-1)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_DOWN,                                        -- When any part of the toolbar is left-clicked, look for a tool.
    function(EV)  IDB=FindTool(EV)  EV:Skip()  end                              -- Use Skip() to avoid interference with native left click handler.
)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,                                          -- When a left click on the toolbar is released, call ReadTool().
    function(EV)  ReadTool(EV)  EV:Skip()  end                                  -- Use Skip() to avoid interference with native left click handler.
)

BANK:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
    function(EV)  BANK:Show(nil)  FRAME:Enable(1)  FRAME:SetFocus(1)  end
)

CNFG:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
    function(EV)  CNFG:EndModal(1)  end
)

function FindTool(Z)                                                            -- Z is reused. Starts as event, becomes tool ID if tool is found.
    Z=TBAR:FindToolForPosition(Z:GetX(),Z:GetY())                               -- When toolbar (or tool) is clicked, look for tool where clicked.
    if Z then  Z=Z:GetId()  end  return Z                                       -- If tool was found, return it's ID, or otherwise return nil.
end

function ReadTool(EV)
    local ID=FindTool(EV)                                                       -- Get the toolbar button's ID, which is how the tool is indexed.
    if (ID~=IDB) then  return  end  IDB=0                                       -- If button down/up were not on same tool, do nothing. Reset IDB.
    if (ID==201) then  BANK:CentreOnParent()  BANK:Show(1)  FRAME:Enable(nil)
    elseif (ID==202) then  CNFG:CentreOnParent()  CNFG:ShowModal(1)
    end
end

FRAME:Centre()  FRAME:Show(wx.TRUE)

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

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

Point taken about the modal dialog being remade locally on demand. I had been doing that before, and was just reconsidering making it global as it didn't appear to be destroyed, and maybe needed no rebuilding, just reshowing. I'll return it to the place it's needed though, as it's neater that way.


That SetFocus() was the wrong one though. You added it to the dialog that works, and I already said that SetFocus() wasn;t solving things, although it appears as if it ought to... That dialog works anyway, somehow, because of the preceding FilePane dialog I think, but I don't know why it makes a difference unless it's something to do with returning focus to the rest of the program. If you add that SetFocus() after the other ShowModal instead, it won't stop that other dialog from failing to respond to any first click. On the other hand, if this doesn't happen for you, it might be something OS specific. It's certainly repeatable here with brutally simple regularity. I can't do anything to shift it.. :)


I was hoping you might say something more about that caveat emptor directory idea. I think it's a good way to make a script available. This is all so new, that in the absence of any documentation other than the source files, surely any kind of working script is worth preserving and distributing intact, so that others can learn from it. If it works, coding style is surely secondary, and no-one's going to confuse it with the formally released samples. Also, if this doesn't happen, it might be rather difficult to persuade anyone else to contribute...

Crow.

Re: [Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

[klaas.holwerda <kho...@xs...>]

Hi,

John Labenski wrote:

>I don't know, hopefully Ray's reading this and can comment, maybe he
>has something, even if it's half done that we can use to bring wxLua
>back to a working state and the rest of us can pitch in to polish it
>off.
>  
>
Please Ray ;-) Can you give us some insight on how the new way will work?
 From that i and we can decide what to do next.
I understand you have more things on your hands ;-), so maybe the best 
way to releaf you is indeed adding what you have so far.
Even if its not ready yet.

>
>I don't know what other's thought of it. Basicly, replace the
>%endclass, %endenum by surrounding them using {} like in c++.
>  
>
Looks a good idea to me.
I don't know whta ctags can do here, but i do know that doxygen 
generates very complete XML on c++ structure.
I would be possible to use it maybe, if better? At least it parses C++ 
correctly in many ways, so that part is done.
But no matter how, if the *.i look like c++ headers, a diff becomes much 
easier.

>  
>
>>The thing is, i will need to have Cmake files in there ( or my own
>>wxart2d  copy ) for wxArt2D.
>>    
>>
>
>I'd like for you to use wxLua itself (if that's what you mean by "my
>own wxart2d copy), just direct people to download it someplace
>relative to your wxArt2D. 
>
That i want too, but can only be true if it has Cmake inside, which you 
have no problem with.

>I think that we can easily have cmake files too, right?
>
Yes.

> Cmake IIRC
>generates the build files on the fly after you download the source and
>run cmake.
>
right. So no polution, and it also generates all stuff outside in a user 
choosen build directory.
This is for me the glory of Cmake, since it makes it very easy to have 
all kinds of setups in parallel.
But bakefile is nice too, although i have to say that it limits the 
things one can do.
This is normal since all one can do is what a makefile can do, and those 
are normally part of the distribution.
With Cmake the users runs cmake (look at it as if it was bakefile), and 
of course this is more flexible in the way things can be setup.

>You
>could put them in the build dir or if there will be a few of them in
>build/cmake right?
>  
>
That is not possible. Since the idea is that the user chooses this build 
directory himself.
So several directories, will get a CMakeLists.txt file, and there will 
be the bin directory for the macros of Cmake.
If you search through wxArt2D for *.txt, you see how it is done (also 
wxLua).
In general those files or no more thten a list of source and header files.
In any case, it is not intrusive i think.
I will try to make it work for what is there now. Although I might wait 
for the coming Cmake2.2, since it has several nice enhancements that 
will make it easier and more clean.

>
>I currently use it with COMPAT_2_4 = 1, I haven't tested it without
>it, but Ray has made the wrapper files generate #if wxCHECK_VER around
>different functions so that it should compile either way. If not, it's
>just a matter of fixing the problems in the .i files and regenerating
>the wrappers. Before we change anything we really have to wait for
>Ray, since doing anything to the wrappers will be a waste of time
>since I think they'll be replaced.
>
>You're right in that we probably should focus on 2.6 since when we're
>done 2.4 will be pretty ancient (it already is to some extent).
>  
>
I will try it. Found why it did not read my setup.h, something stupid on 
my side ;-)
The things is that it reads setup.h from a place that is maybe not the best.
setup.h is copied to each flavour in the resulting lib of wxWidgets.
So one things that one is in use, while it lua reads another 
$WXWIN/include/wx/msw/setup.h
Is that one changes, one needs to remove the ones in the lib dirs, to 
make fresh copies.
All a bit confusing.
I think wxWidgets has bin setup to use setup.h from the lib dirs, it is 
first in the include path.
The other one is just there as a template for changing. So a way to have 
several settings/setups for libraries, without automatically 
overwritting the ones compiled already. This is what Cmake solves more 
elegant ;-) But at least wxWidgets has  done something to be able to do 
several types of setup.h files around. So i think we should read the 
last in the lib dirs. 2.5.0 > does this all like that, so if we skip on 
2.4.0, we are save.
 

>I hope this helps, I hope we can get going again...
>  
>
Yes thanks a lot!

I wish i knew a bit more of wxLua in order to help you, but i am afraid 
that  i have to the depend  on you and Ray to make a start,  then i will 
do my best to  join. wxArt2D is taken most of my time, but once wxLua is 
nicely in adding extrernal wrappers, that will save time there ;-)

Best regards,

Klaas


 

Re: [Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

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

On 7/29/05, k. holwerda <kla...@nl...> wrote:
> I am still using the/my old wxLua  inside wxArt2D. Hoping for wxLua CVS
> to become usable, but maybe it already is?

It currently doen't wrap "enums" and "builtin" functions in the cpp
wrapper files. It does compile and work otherwise. I cannot figure it
out, but gave up since we're going to get some new wrappers anyway.

> Referring to non use of *.i files or at least other ways to generate
> them using Ray his ideas.
>=20
> What impact will all that have on the current structure? Will the *.i
> files stay? Or will it be  a new aproach ?

I don't know, hopefully Ray's reading this and can comment, maybe he
has something, even if it's half done that we can use to bring wxLua
back to a working state and the rest of us can pitch in to polish it
off.

I made some suggestions about making the .i files look more like c++
so that making your own would be a simple matter of taking a header
file and just removing the stuff you don't want. You'd then be able to
run a diff program on the .i and the original header to compare. But,
I don't know what other's thought of it. Basicly, replace the
%endclass, %endenum by surrounding them using {} like in c++.

> The thing is, i will need to have Cmake files in there ( or my own
> wxart2d  copy ) for wxArt2D.

I'd like for you to use wxLua itself (if that's what you mean by "my
own wxart2d copy), just direct people to download it someplace
relative to your wxArt2D. That way we avoid the splintering we had
before. Remixing together code from various places is error prone and
laborous. Hopefully it'll work soon...

I think that we can easily have cmake files too, right? Cmake IIRC
generates the build files on the fly after you download the source and
run cmake. If the files it generates are given names that won't clash
with the files in CVS it'll be easy to have both of them together. You
could put them in the build dir or if there will be a few of them in
build/cmake right?

> In any case, i would like to know is the current version can be compiled
> with wx261, and if that is with
>=20
> #define WXWIN_COMPATIBILITY_2_4 1
> i think it should be:
> #define WXWIN_COMPATIBILITY_2_4 0
> as setup.h recomments.

I currently use it with COMPAT_2_4 =3D 1, I haven't tested it without
it, but Ray has made the wrapper files generate #if wxCHECK_VER around
different functions so that it should compile either way. If not, it's
just a matter of fixing the problems in the .i files and regenerating
the wrappers. Before we change anything we really have to wait for
Ray, since doing anything to the wrappers will be a waste of time
since I think they'll be replaced.

You're right in that we probably should focus on 2.6 since when we're
done 2.4 will be pretty ancient (it already is to some extent).

> And how does one tell wxLuaWrap.lua, does it really read the setup.h?

It tries to find your wxWidgets setup.h file the best it can and sets
values from it. See bindings/wxluawrap.lua and at the top there is
code to look for "wxSetup_h" if it's nil. You can also specify
wxSetup_h before you run wxluawrap.lua if the code fails for some
reason.

I hope this helps, I hope we can get going again...
    John Labenski

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

On 7/28/05, The Doctor <the...@bl...> wrote:
> I found some possible problem with that extended toolbar thing.
>=20
> A dialog, directly called by tool click, doesn't have focus correctly, an=
d I don't yet know why. It takes a click on the main app title bar, or on t=
he dialog space, or on the close button on the dialog itself, before any at=
tempt to close the dialog window will work. It's as if the focus is somewhe=
re completely hidden, and must be recalled before a manual response works.
> Do you have any idea why this happens? Also, might some simple method by =
applied to make sure the focus or whatever it is allows a proper response t=
o the first click on the program windows? (I tried a SetFocus() on the dial=
og after ShowModal() but that didn't fix it).

dialog:SetFocus() seems to work for me? See "function ReadTool(EV)".

Also note that modal dialogs like the file dialog should be local
variables to the function that they're called from since they block
program flow and it's just as well to create them as necessary. Native
dialogs like the file dialog may be destroyed when done. See where
I've moved FilePane into "DoThings".

Regards,
    John Labenski

> -------------------------------------------------------------------------=
--------------------------
>=20
> local FS=3Dwx.wxDEFAULT_FRAME_STYLE-wx.wxMAXIMIZE_BOX-wx.wxRESIZE_BORDER
> FRAME=3Dwx.wxFrame(wx.wxNull,-1,"",wx.wxDefaultPosition,wx.wxSize(432,310=
),FS)    -- Main GUI frame, supports menus and all good stuffs.
>=20
> PANEL=3Dwx.wxPanel(FRAME,-1)                                             =
         -- Dialog-like control/surface in a Frame.
>=20
> BANK=3Dwx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))     =
         -- Make two identical test dialogs.
> CNFG=3Dwx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))
>=20
> IDB=3D0
>=20
> BMP_I=3Dwx.wxBitmapFromFile("Bitmaps/new.bmp",wx.wxBITMAP_TYPE_BMP)
> BMP_O=3Dwx.wxBitmapFromFile("Bitmaps/open.bmp",wx.wxBITMAP_TYPE_BMP)
> TBAR=3Dwx.wxToolBar(PANEL,ID_TOOLBAR,wx.wxPoint(-1,14),wx.wxSize(-1,-1),w=
x.wxTB_FLAT)
> TBAR:AddTool(201,BMP_I,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
> TBAR:AddTool(202,BMP_O,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
> TBAR:Realize()  TBAR:Move(-1,-2)  TBAR:SetSize(440,-1)
>=20
> TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_DOWN,                                 =
       -- When any part of the toolbar is left-clicked, look for a tool.
>     function(EV)  IDB=3DFindTool(EV)  EV:Skip()  end                     =
         -- Use Skip() to avoid interference with native left click handler=
.
> )
>=20
> TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,                                   =
       -- When a left click on the toolbar is released, call ReadTool().
>     function(EV)  ReadTool(EV)  EV:Skip()  end                           =
       -- Use Skip() to avoid interference with native left click handler.
> )
>=20
> BANK:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
>     function(EV)  BANK:EndModal(1)  end
> )
>=20
> CNFG:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
>     function(EV)  CNFG:EndModal(1)  end
> )
>=20
> function FindTool(Z)
>     Z=3DTBAR:FindToolForPosition(Z:GetX(),Z:GetY())                      =
         -- When toolbar (or tool) is clicked, look for tool where clicked.
>     if Z then  Z=3DZ:GetId()  end  return Z                              =
         -- If tool was found, return it's ID, or otherwise return nil.
> end
>=20
> function DoThings()
>    FilePane=3Dwx.wxFileDialog(FRAME,"","","","All files  (*.*)|*.*",wx.wx=
OPEN)
>     FilePane:ShowModal()  --FilePane:EndModal(1)
>     CNFG:CentreOnParent()  CNFG:ShowModal(wx.TRUE)                       =
       -- Show selector dialog. Button ID will be set to VN (Voice Number).
> end
>=20
> function ReadTool(EV)
>     local ID=3DFindTool(EV)                                              =
         -- Get the toolbar button's ID, which is how the tool is indexed.
>     if (ID~=3DIDB) then  return  end  IDB=3D0                            =
           -- If button down/up were not on same tool, do nothing. Reset ID=
B.
>     if (ID=3D=3D201) then  BANK:CentreOnParent()  BANK:ShowModal(wx.TRUE)=
 BANK:SetFocus()
>     elseif (ID=3D=3D202) then  DoThings()
>     end
> end
>=20
> FRAME:Centre()
> FRAME:Show(wx.TRUE)
> -------------------------------------------------------------------------=
--------------------------

[Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

[k. h. <kla...@nl...>]

Hi John,

I am still using the/my old wxLua  inside wxArt2D. Hoping for wxLua CVS 
to become usable, but maybe it already is?
Referring to non use of *.i files or at least other ways to generate 
them using Ray his ideas.

What impact will all that have on the current structure? Will the *.i 
files stay? Or will it be  a new aproach ?

The thing is, i will need to have Cmake files in there ( or my own 
wxart2d  copy ) for wxArt2D.
If the whole think is about to change i better wait, but if not, i will 
start on the current situation.
If i have the right Cmake files, i can add them to wxLua CVS or keep 
them seperate.
I think it would be best to add them, else i will need to find a way to 
combine at a latter stage in wxAr2tD, which is no fun.

In any case, i would like to know is the current version can be compiled 
with wx261, and if that is with

#define WXWIN_COMPATIBILITY_2_4 1

i think it should be:
 
#define WXWIN_COMPATIBILITY_2_4 0

as setup.h recomments.

And how does one tell wxLuaWrap.lua, does it really read the setup.h?

Thanks,

Klaas

Unclassified

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

A correction of previous mail:

"(my first one calls a save or load dialog before calling a dialog I made for other stuff)"

Should read:

(my first example was in the Thinger program, which calls a save or load dialog before calling a dialog I made for other stuff)

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

I found some possible problem with that extended toolbar thing.

A dialog, directly called by tool click, doesn't have focus correctly, and I don't yet know why. It takes a click on the main app title bar, or on the dialog space, or on the close button on the dialog itself, before any attempt to close the dialog window will work. It's as if the focus is somewhere completely hidden, and must be recalled before a manual response works.

I've included some code showing this. The first button calls the dialog directly. The second first calls a save dialog, which on closing calls a test dialog identical to that called by the first button. This second one works. This is why I never noticed the problem before (my first one calls a save or load dialog before calling a dialog I made for other stuff). It was only when I wanted to make a new one for config settings, that I saw this.

Do you have any idea why this happens? Also, might some simple method by applied to make sure the focus or whatever it is allows a proper response to the first click on the program windows? (I tried a SetFocus() on the dialog after ShowModal() but that didn't fix it).



The code:

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

local FS=wx.wxDEFAULT_FRAME_STYLE-wx.wxMAXIMIZE_BOX-wx.wxRESIZE_BORDER
FRAME=wx.wxFrame(wx.wxNull,-1,"",wx.wxDefaultPosition,wx.wxSize(432,310),FS)    -- Main GUI frame, supports menus and all good stuffs.

PANEL=wx.wxPanel(FRAME,-1)                                                      -- Dialog-like control/surface in a Frame.

FilePane=wx.wxFileDialog(FRAME,"","","","All files  (*.*)|*.*",wx.wxOPEN)

BANK=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))              -- Make two identical test dialogs.
CNFG=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))

IDB=0

BMP_I=wx.wxBitmapFromFile("Bitmaps/new.bmp",wx.wxBITMAP_TYPE_BMP)
BMP_O=wx.wxBitmapFromFile("Bitmaps/open.bmp",wx.wxBITMAP_TYPE_BMP)
TBAR=wx.wxToolBar(PANEL,ID_TOOLBAR,wx.wxPoint(-1,14),wx.wxSize(-1,-1),wx.wxTB_FLAT)
TBAR:AddTool(201,BMP_I,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
TBAR:AddTool(202,BMP_O,wx.wxNullBitmap,wx.FALSE,wx.wxNull,"")
TBAR:Realize()  TBAR:Move(-1,-2)  TBAR:SetSize(440,-1)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_DOWN,                                        -- When any part of the toolbar is left-clicked, look for a tool.
    function(EV)  IDB=FindTool(EV)  EV:Skip()  end                              -- Use Skip() to avoid interference with native left click handler.
)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,                                          -- When a left click on the toolbar is released, call ReadTool().
    function(EV)  ReadTool(EV)  EV:Skip()  end                                  -- Use Skip() to avoid interference with native left click handler.
)

BANK:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
    function(EV)  BANK:EndModal(1)  end
)

CNFG:ConnectEvent(-1,wx.wxEVT_COMMAND_BUTTON_CLICKED,
    function(EV)  CNFG:EndModal(1)  end
)

function FindTool(Z)
    Z=TBAR:FindToolForPosition(Z:GetX(),Z:GetY())                               -- When toolbar (or tool) is clicked, look for tool where clicked.
    if Z then  Z=Z:GetId()  end  return Z                                       -- If tool was found, return it's ID, or otherwise return nil.
end

function DoThings()
    FilePane:ShowModal()  --FilePane:EndModal(1)
    CNFG:CentreOnParent()  CNFG:ShowModal(wx.TRUE)                              -- Show selector dialog. Button ID will be set to VN (Voice Number).
end

function ReadTool(EV)
    local ID=FindTool(EV)                                                       -- Get the toolbar button's ID, which is how the tool is indexed.
    if (ID~=IDB) then  return  end  IDB=0                                       -- If button down/up were not on same tool, do nothing. Reset IDB.
    if (ID==201) then  BANK:CentreOnParent()  BANK:ShowModal(wx.TRUE)
    elseif (ID==202) then  DoThings()
    end
end

FRAME:Centre()
FRAME:Show(wx.TRUE)
---------------------------------------------------------------------------------------------------

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(26/07/2005 04:56)

>> Why use parts of it and not the whole? I'd like it used as it is, or near enough, as I solved several significant obstacles to handling tools on a toolbar, which as you say, don't behave as ordinary windows do. My coding style is not standard, but it's consistent, compact and efficient, and even that's secondary to to the content.
>
>Well, stuff like this should be changed, you're passing the event
>which you call "Z" ? and then take that variable and overwrite it with
>the tool from FindToolForPosition then proceed to overwrite it with
>the numeric window id of the tool and return Z (the variable that was
>passed in originally?). It's easy to get confused by this, you're
>returning an event? or a tool? or a window id? Have typos been made?
>Who knows?
>
>>function FindTool(Z)
>>   Z=TBAR:FindToolForPosition(Z:GetX(),Z:GetY())     
>>   if Z then  Z=Z:GetId()  end  return Z                        
>>end
>> 


That's just a different style. :) It's confusing without familiar context, I guess, but it serves two main purposes this way. One is the reuse of a single variable, which saves space on the page as well as in RAM, which though not as vital as it is when programming a Psion Organiser II XP in OPL, is still a very good habit to keep. The second I find more important, the use of a single arbitrary letter, and a single variable, immediately signifies that only one entity is being handled at a time, processed in stages for return. I guess I could have made a comment that the incoming item is an event, but the calling code makes that clear anyway. I take your point that the variable names could be self-commenting, but I decided the function names wxLua provided went a long way to doing just that. :)

When I need globals I have a different system. I usually use two, three, or four letters, abbreviations or acronyms usually, or consonant phonetic shorthands, chosen carefully for unique unambiguous use, like TBAR will always mean toolbar, MBAR always menubar, SBAR always status bar... Either way I'll usually declare them all in a group near the top of the page, so it's a sort of glossary.

As to what that function returns, I commented that fully, I decided I found the use of a right-hand column for comments to be clearer than mixing them with the code. I try to stick to a line for line relation, so a comment usually relates to the code on the same line. That allows for very detailed narrative, a bit like ball by ball commentary in cricket. :) It's flawed, and I'm developing the trick as I work, but I like it this way.

>I think that people will get a better understanding and learn quicker
>from code written like this. The variables have names that tell you
>exactly what you expect them to contain. The function takes a toolBar
>and a mouseEvent and returns a window id or nil on failure. It
>documents itself, even telling you what the FindToolForPosition
>returns so the reader doesn't have to look it up.
>
>function FindTool(toolBar, mouseEvent)
>   local toolBarTool =
>toolBar:FindToolForPosition(mouseEvent:GetX(),mouseEvent:GetY())
>   local win_id = nil
>   if toolBarTool then  win_id = toolBarTool:GetId() end  
>   return win_id
>end
>

Again, I do see your point, but to me, this is actually very confusing. The reason is that when faced with a new system I'm always struggiling with code like this. I have to thrash around trying to work out which are user variable names, and which are function names for built-in stuff. The stuff I learned from was old BASIC and OPL stuff, and the idea there was to use as few variables as possible, to reuse where you can, especially locally within a function, and to use single letters, or names that are obviously related to the users purpose, in no way confusable with existing function names. I also tend to use capitals for variables, again to distinguish them from inbuilt function names, which rarely used caps, then or now.


>Sure we can give you credit, but we want a minimal set of programs
>that 1) demo wxLua features, 2) teach how to write clean, robust wxLua
>code, 3) stress test the library, and 4) are easy to understand.
>Remember that every bit of code has to be maintained and checked, even
>now some of the samples don't work properly. I really don't want to
>discourage you, the sample program is fine, it shows a lot, but took
>me bit to understand it.

No problem. :) I'm not discouraged, quite the reverse, I'm glad you took the time to go through it. I'm just trying to find a way to please us both. My idea is that you take freely what you want, after all I don't own any rights to stop good use of code, and that way you can use it as you want, but at same time, keep the original in the caveat emptor box for people to see in original form. If you take a whole working chunk and re-write it, maybe add a one-line comment to say that it's reworked from script xyz.lua in the user submissions directory, so people can see it written both ways. Some will find your way easier, others will find mine so, and seeing both is surely the best of both worlds. :)

Crow.

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

On 7/23/05, The Doctor <the...@bl...> wrote:
> >Thanks, the samples probably need to be cleaned up a bit. Nothing
> >special, just make them have the same coding style and demo a couple
> >more things. I'll add parts of this once we get the c++ side going
> >again.
>=20
> Why use parts of it and not the whole? I'd like it used as it is, or near=
 enough, as I solved several significant obstacles to handling tools on a t=
oolbar, which as you say, don't behave as ordinary windows do. My coding st=
yle is not standard, but it's consistent, compact and efficient, and even t=
hat's secondary to to the content.

Well, stuff like this should be changed, you're passing the event
which you call "Z" ? and then take that variable and overwrite it with
the tool from FindToolForPosition then proceed to overwrite it with
the numeric window id of the tool and return Z (the variable that was
passed in originally?). It's easy to get confused by this, you're
returning an event? or a tool? or a window id? Have typos been made?
Who knows?

function FindTool(Z)
   Z=3DTBAR:FindToolForPosition(Z:GetX(),Z:GetY())    =20
   if Z then  Z=3DZ:GetId()  end  return Z                       =20
end
=20
I think that people will get a better understanding and learn quicker
from code written like this. The variables have names that tell you
exactly what you expect them to contain. The function takes a toolBar
and a mouseEvent and returns a window id or nil on failure. It
documents itself, even telling you what the FindToolForPosition
returns so the reader doesn't have to look it up.

function FindTool(toolBar, mouseEvent)
   local toolBarTool =3D
toolBar:FindToolForPosition(mouseEvent:GetX(),mouseEvent:GetY())
   local win_id =3D nil
   if toolBarTool then  win_id =3D toolBarTool:GetId() end =20
   return win_id
end

> In the samples, where there is a significant original work to demonstrate=
 features of wxLua, there is an intact script with the credit of the author=
 intact in it. I'd like mine to be treated the same way. What about having =
a second directory of samples from users, left entirely intact, on a caveat=
 emptor basis? :) That way I get full credit, at least somewhere in the dis=
tribution, for my help for it, and others can learn from it as I learned fo=
r myself, from whatever intact examples I find. Sometimes it's better to se=
e various sources, rather than one central interpretation. This helped me i=
n JavaScript, and the same probably applies to wxLua. If nothing else, if y=
ou do this, any eccentricity or flaw in the code will be solely credited to=
 me, as well as any merit.

Sure we can give you credit, but we want a minimal set of programs
that 1) demo wxLua features, 2) teach how to write clean, robust wxLua
code, 3) stress test the library, and 4) are easy to understand.
Remember that every bit of code has to be maintained and checked, even
now some of the samples don't work properly. I really don't want to
discourage you, the sample program is fine, it shows a lot, but took
me bit to understand it.

Regards,
    John Labenski

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(22/07/2005 23:14)

>
>local r = toolBar:GetRect() 
>print(r:GetX(), r:GetY(), r:GetRight(), r:GetBottom())
>
>as well as the mouse event you get. Maybe that will help make sense of
>it? Also use toolBar:GetToolSize(). Finally the position you're using
>is in pixels so you should use y = toolheight/2 and x = toolwidth/2 to
>guarantee you're actually on a button, x = 0 might be your problem.
>

I worked out the tool position, and the no-go areas. 0 is no problem, but it is possible to overshoot vertically by one pixel into the blank toolbar space... Anyway, FindToolForPosition() doesn't have any of those problems, and getting the rects wouldn't help if the code hadn't identified which tool I was pointing at. :) It was an oversight of mine though, as I showed in the third of yesterday's mails, I just used GetX() and GetY() to get co-ords in the right format.


>Hopefully, once you get used to it it'll make more sense. wxWidgets is
>a complicated system and since it uses native controls, it has to work
>around bugs and oddities with them finding a happy middle ground. I
>think it does well, but it takes some getting used to.

Agreed. It does do very well. It's stable, and I trust it. I like that it is possible to work round things and get a consistent result. I hope my own thing with the toolbar script has tied into this nicely. It appears to be ok, as it uses things already built in to wxLua to overcome obstacles. What I value most is having a way of working that remains consistent and powerful, and I'll go a long way out of range to get that, so that later I can use the modularised results.

To whoever it was that decided to incorporate FindToolForPosition() into wxLua, thankyou, as that is a great example of a single function allowing a huge advance in overcoming problems accessing tools. Having looked at the options that were not included in wxLua (like FindById()), I came to see that if any single one be chosen and none of the others that might help, this one is by far the most useful. A good choice.

>
>Toolbar tools are NOT real windows and do not have the same
>functionality as a wxWindow (again that's why I suggest using
>buttons). When I say they're a black hole, it's because it's that way
>in MSW and GTK. Both widget sets have almost no capability to do the
>things you want. They're some sort of container that probably draws
>the tools itself and they didn't bother to write functions to get at
>where they're drawn. Therefore wxWidgets doesn't have them either. I
>hate it too and have tried many times to work around it, eventually I
>give up and use a button (usually combobox) and then knowing where
>that is, figure out where the other tools are.
>

ok :) I solved what I needed to solve though. I knew there were limits, that they are not real windows, but I knew that there should be a way past that particular limit, and it turned out to be so. In this case it was using code that could find the tool and recover it's ID if the pointer was sitting on it. I'll try to seperate single from double clicks too, maybe, but I'll have to investigate some kind of timer for that, as time is the the only thing that truly seperates them, as no double click can occur without generating a button-up or button-down event... Not important though, I have more than enough possible controls branching off a single tool now. >:)

Thanks for your help, it beats having to do it all alone.

Crow.

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(22/07/2005 22:32)

>Thanks, the samples probably need to be cleaned up a bit. Nothing
>special, just make them have the same coding style and demo a couple
>more things. I'll add parts of this once we get the c++ side going
>again.
>

Why use parts of it and not the whole? I'd like it used as it is, or near enough, as I solved several significant obstacles to handling tools on a toolbar, which as you say, don't behave as ordinary windows do. My coding style is not standard, but it's consistent, compact and efficient, and even that's secondary to to the content.

In the samples, where there is a significant original work to demonstrate features of wxLua, there is an intact script with the credit of the author intact in it. I'd like mine to be treated the same way. What about having a second directory of samples from users, left entirely intact, on a caveat emptor basis? :) That way I get full credit, at least somewhere in the distribution, for my help for it, and others can learn from it as I learned for myself, from whatever intact examples I find. Sometimes it's better to see various sources, rather than one central interpretation. This helped me in JavaScript, and the same probably applies to wxLua. If nothing else, if you do this, any eccentricity or flaw in the code will be solely credited to me, as well as any merit.


>You already have word wrap off, and it makes responding to your
>messages difficult, but in this case it works well. :)
>

This is why most clients have wordwrap for viewing. :) I decided that this was better, as I can always see the size of my own windows, but rarely the size of anyone elses.
To be fair, most email clients make this weird mistake, hell knows why..

Crow.

Re: [Wxlua-users] ControlDown?

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

On 7/22/05, The Doctor <the...@bl...> wrote:
> Hi John, I have an answer, of sorts, having made FindToolForPosition() wo=
rk...
>=20
> TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
>     function(EV)  ID=3DTBAR:FindToolForPosition(0,1):GetId()  if (EV:Cont=
rolDown()) then  DoThings(ID)  end  EV:Skip()  end
> )
>=20
> This will detect the first tool, but is no better than manually specifyin=
g the ID. I'd also have to test for the presence of the tool before trying =
to GetId(), or there would be error. That's easy but what I really want is =
TBAR:FindToolForPosition(EV:GetPosition()). That would allow a single handl=
er and a single function called by it, to handle any tool, and any state fo=
r Ctrl or Shift or Alt keys while clicking it with either mouse button.
>=20
> The only thing stopping me from getting at this wonderful power is the mi=
nd-numbingly annoying incompatibility in the way co-ordinates are handled.
>=20
> Surely it's not too much to expect that GetPosition() can return co-ordin=
ates in a form that FindToolForPosition() can use?! I guess it is though. I=
s there a way to convert?

I haven't tried this at all, you can print out the rects of the
different things. Starting with

local r =3D toolBar:GetRect()=20
print(r:GetX(), r:GetY(), r:GetRight(), r:GetBottom())

as well as the mouse event you get. Maybe that will help make sense of
it? Also use toolBar:GetToolSize(). Finally the position you're using
is in pixels so you should use y =3D toolheight/2 and x =3D toolwidth/2 to
guarantee you're actually on a button, x =3D 0 might be your problem.

> It's things like this that keep me slow and asking confusing questions. T=
he trouble with wxWidgets, (or wxLua, I'm not quite sure which) is that unl=
ike Lua itself, so much is done with specific behaviours that don't seem to=
 talk well to each other, except via black boxes whose behaviour alone is a=
ll I have to go on to understand them.=20

Hopefully, once you get used to it it'll make more sense. wxWidgets is
a complicated system and since it uses native controls, it has to work
around bugs and oddities with them finding a happy middle ground. I
think it does well, but it takes some getting used to.

>In Lua, the emphasis is on a simple versatile system that can be
adapted to many ways of working. This is partway possible with wxLua
too, but the most versatile forms seem to involve catching mouse
events, but I keep being thwarted with proplems like lack of
propagation, or mismatches in co-ordinate handling methods, or
problems getting ID's for things, of finding those things to be
userdata and finding no way to know what exactly that userdata is.

We can write a method to print the userdata type I think. That would
definitely be handy. In addition to that I think it should be easily
possible to generate info about what's wrapped for each control from
the c++ side and somehow make this printable in lua.

> To illustrate that last point, I can do this:
>=20
> ID=3DTBAR:FindToolForPosition(0,1):GetId()
>=20
> Which seems to imply that TBAR:FindToolForPosition(0,1) will point to the=
 actual tool.
> If it did, I could do this:
>=20
> X=3DTBAR:FindToolForPosition(0,1)
> X:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
>     function(EV)  stuff...  end
> )
>=20
> This won't go. ConnectEvent is invalid in this case. Whatever X is, it's =
not the tool! And I have no way to know what it is.

Toolbar tools are NOT real windows and do not have the same
functionality as a wxWindow (again that's why I suggest using
buttons). When I say they're a black hole, it's because it's that way
in MSW and GTK. Both widget sets have almost no capability to do the
things you want. They're some sort of container that probably draws
the tools itself and they didn't bother to write functions to get at
where they're drawn. Therefore wxWidgets doesn't have them either. I
hate it too and have tried many times to work around it, eventually I
give up and use a button (usually combobox) and then knowing where
that is, figure out where the other tools are.

Regards,
    John Labenski

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

On 7/22/05, The Doctor <the...@bl...> wrote:
> This is something I worked up today, to solve some problems. I decided to=
 make it a full demonstration, which I'd like to add to the set of example =
files distributed with wxLua. There might be things that need changing or i=
mproving first, but it works well in Windows, and I avoided things that loo=
ked like they might not work elsewhere. It certainly needs testing. :)

Thanks, the samples probably need to be cleaned up a bit. Nothing
special, just make them have the same coding style and demo a couple
more things. I'll add parts of this once we get the c++ side going
again.

> You'll need word-wrap off to see this clearly, as I put comments in a sec=
ond column. If the mailing system screws it up, please let me know some oth=
er way to make it available. Does the list accept attachments?

You already have word wrap off, and it makes responding to your
messages difficult, but in this case it works well. :)

Regards,
    John Labenski

[Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

This is something I worked up today, to solve some problems. I decided to make it a full demonstration, which I'd like to add to the set of example files distributed with wxLua. There might be things that need changing or improving first, but it works well in Windows, and I avoided things that looked like they might not work elsewhere. It certainly needs testing. :)

You'll need word-wrap off to see this clearly, as I put comments in a second column. If the mailing system screws it up, please let me know some other way to make it available. Does the list accept attachments?

Crow.



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

-- Extended ToolBar example, by Lostgallifreyan. 22/07/05.
-- This overrides standard behaviour but emulates it exactly while extending it to allow very versatile controls to be got from a very small number of tools.
-- The purpose is to allow motor memory as well as visual memory to play a big part in program control, as this is faster amd easier to remember with practise.
-- It reduces the clutter of controls and event handlers that would be needed if dedicated controls had to be used for everything, and allows useful grouping.




local FS=wx.wxDEFAULT_FRAME_STYLE-wx.wxMAXIMIZE_BOX-wx.wxRESIZE_BORDER          -- Set Frame Style for fixed size; reduced border saves space.

FRAME=wx.wxFrame(wx.wxNull,-1,"Tools",wx.wxPoint(0,0),wx.wxSize(140,140),FS)    -- Main GUI frame, supports menus and all good stuffs.

PANEL=wx.wxPanel(FRAME,-1)                                                      -- Dialog-like control/surface in a Frame.

TBAR=wx.wxToolBar(PANEL,wx.wxID_TOOLBAR,wx.wxPoint(-1,-1),wx.wxSize(-1,-1))     -- Toolbar. Size and position are best set after it is prepared.

local BMP_N=wx.wxBitmapFromFile("bitmaps/new.bmp",wx.wxBITMAP_TYPE_BMP)         -- Prepare the toolbar button bitmaps.
local BMP_O=wx.wxBitmapFromFile("bitmaps/open.bmp",wx.wxBITMAP_TYPE_BMP)
local BMP_S=wx.wxBitmapFromFile("bitmaps/save.bmp",wx.wxBITMAP_TYPE_BMP)
TBAR:AddTool(wx.wxID_NEW,BMP_N,wx.wxNullBitmap,wx.FALSE,wx.wxNull)              -- Add the prepared tools to the toolbar.
TBAR:AddTool(wx.wxID_OPEN,BMP_O,wx.wxNullBitmap,wx.FALSE,wx.wxNull)
TBAR:AddTool(wx.wxID_SAVE,BMP_S,wx.wxNullBitmap,wx.FALSE,wx.wxNull)
TBAR:Realize()  TBAR:Move(-1,-2)  TBAR:SetSize(140,-1)                          -- Render the toolbar, setting size and position for best display.

TEXT="Click a tool button.\nOr try double-click. :)\n"                          -- Set some initial descriptive text shown when the program is run.
TEXT=TEXT.."Try it while holding\nCtrl, or Shift, or Alt,\n"
TEXT=TEXT.."or any mix of them..."
TEXT=wx.wxStaticText(PANEL,-1,TEXT,wx.wxPoint(0,32),wx.wxSize(140,80))

TOOL={"Open",0,"New","Save"}                                                    -- Table of names for tools used in this example. '0' is unused.
MCLK={"Left Click","Right Click","Left Dbl-Click","Right Dbl-Click"}            -- Table of names for Mouse Click types, used in text display.
IDB=0                                                                           -- ID Buffer, used in detection of properly applied mouse clicks.

function ReadTool(EV,MC)
    local ID=FindTool(EV)                                                       -- Get the toolbar button's ID, which is how the tool is indexed.
    if (ID~=IDB) then  return  end  IDB=0                                       -- If button down/up were not on same tool, do nothing. Reset IDB.
    if ID then  ID="Tool Used:  "..TOOL[ID-4999]..", ID="..ID.."\n\n"           -- Set display text describing the tool used, or the toolbar space.
    else ID="Tool Used:  Toolbar space.\n\n"
    end
    MC="Click Type:  "..MCLK[MC].."\n\n"                                        -- Set display text describing the type of mouse click applied.
    local KEYS="Keys Held: "                                                    -- Set display text describing any combination of keys held.
    if (EV:ControlDown()) then  KEYS=KEYS.." Control"  end
    if (EV:ShiftDown()) then  KEYS=KEYS.." Shift"  end
    if (EV:AltDown()) then  KEYS=KEYS.." Alt"  end
    TEXT:SetLabel(ID..MC..KEYS)                                                 -- Render the decriptions as a single block of multi-line text.
end

function FindTool(Z)
    Z=TBAR:FindToolForPosition(Z:GetX(),Z:GetY())                               -- When toolbar (or tool) is clicked, look for tool where clicked.
    if Z then  Z=Z:GetId()  end  return Z                                       -- If tool was found, return it's ID, or otherwise return nil.
end

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_DOWN,                                        -- When any part of the toolbar is left-clicked, look for a tool.
    function(EV)  IDB=FindTool(EV)  EV:Skip()  end                              -- Use Skip() to avoid interference with native left click handler.
)

TBAR:ConnectEvent(-1,wx.wxEVT_RIGHT_DOWN,                                       -- When any part of the toolbar is right-clicked, look for a tool.
    function(EV)  IDB=FindTool(EV)  end
)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,                                          -- When a left click on the toolbar is released, call ReadTool().
    function(EV)  ReadTool(EV,1)  EV:Skip()  end                                -- Use Skip() to avoid interference with native left click handler.
)

TBAR:ConnectEvent(-1,wx.wxEVT_RIGHT_UP,                                         -- When a right click on the toolbar is released, call ReadTool().
    function(EV)  ReadTool(EV,2)  end
)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,                                      -- When the toolbar is left double-clicked, call ReadTool().
    function(EV)  IDB=FindTool(EV)  ReadTool(EV,3)  end                         -- Set IDB for current tool, so that ReadTool() accepts the event.
)

TBAR:ConnectEvent(-1,wx.wxEVT_RIGHT_DCLICK,                                     -- When the toolbar is right double-clicked, call ReadTool().
    function(EV)  IDB=FindTool(EV)  ReadTool(EV,4)  end                         -- Set IDB for current tool, so that ReadTool() accepts the event.
)

FRAME:Centre()  FRAME:Show(wx.TRUE)                                             -- Render the program window, centred in the screen.


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

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  
    ID=TBAR:FindToolForPosition(EV:GetX(),EV:GetY()):GetId()  
    if (EV:ControlDown()) then  DoThings(ID,"C")  else  DoThings(ID)  end 
    EV:Skip()  end
)




:)

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

Hi John, I have an answer, of sorts, having made FindToolForPosition() work...

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  ID=TBAR:FindToolForPosition(0,1):GetId()  if (EV:ControlDown()) then  DoThings(ID)  end  EV:Skip()  end
)

This will detect the first tool, but is no better than manually specifying the ID. I'd also have to test for the presence of the tool before trying to GetId(), or there would be error. That's easy but what I really want is TBAR:FindToolForPosition(EV:GetPosition()). That would allow a single handler and a single function called by it, to handle any tool, and any state for Ctrl or Shift or Alt keys while clicking it with either mouse button.

The only thing stopping me from getting at this wonderful power is the mind-numbingly annoying incompatibility in the way co-ordinates are handled.

Surely it's not too much to expect that GetPosition() can return co-ordinates in a form that FindToolForPosition() can use?! I guess it is though. Is there a way to convert?

It's things like this that keep me slow and asking confusing questions. The trouble with wxWidgets, (or wxLua, I'm not quite sure which) is that unlike Lua itself, so much is done with specific behaviours that don't seem to talk well to each other, except via black boxes whose behaviour alone is all I have to go on to understand them. In Lua, the emphasis is on a simple versatile system that can be adapted to many ways of working. This is partway possible with wxLua too, but the most versatile forms seem to involve catching mouse events, but I keep being thwarted with proplems like lack of propagation, or mismatches in co-ordinate handling methods, or problems getting ID's for things, of finding those things to be userdata and finding no way to know what exactly that userdata is.

To illustrate that last point, I can do this:

ID=TBAR:FindToolForPosition(0,1):GetId()

Which seems to imply that TBAR:FindToolForPosition(0,1) will point to the actual tool.
If it did, I could do this:

X=TBAR:FindToolForPosition(0,1)
X:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  stuff...  end
)

This won't go. ConnectEvent is invalid in this case. Whatever X is, it's not the tool! And I have no way to know what it is.

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(21/07/2005 22:11)

>Instead of storing variables to your controls, you can get them from
>the events. Try this.
>
>    local toolBar = frame:CreateToolBar()
>    toolBar:AddTool(100, bmp)
>    bmpButton = wx.wxBitmapButton(toolBar, 101, bmp)
>    toolBar:AddControl(bmpButton)
>    toolBar:Realize()
>    
>    function bmpButtonHandler(event)
>       local bmpButton = event:GetEventObject():DynamicCast("wxBitmapButton")
>       print(bmpButton) -- this is the button itself
>    end
>    bmpButton:ConnectEvent(101, wx.wxEVT_COMMAND_BUTTON_CLICKED,
>bmpButtonHandler)
>

But that's exactly what I don't want to do. I already tested a way to put a control on the toolbar, but what I want to do is reference a tool with a variable. The only reason I tried adding the control was to prove it could work with my existing code idea. If I could make the tool in advance, I could store it to the variable: X=MakeTool() TBAR:AddTool(X)  -- if MakeTool() existed. That would then allow this, which would work exactly as I want:

X:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  if (EV:ControlDown()) then  DoThings()  end  EV:Skip()  end
)

As it is, using TBAR as before, I can make it work by testing the flag, which is unset when any tool is clicked, but if the user holds control and clickes a blank bit of toolbar, the flag will get set, and if they then click the button that has this alternative function activated by Ctrl, they'll invoke said function even without holding Ctrl. Awkward... The only fix seems to be to make the toolbar exactly the same size as the buttons on it, to minimise misfires. A workround I've been trying is some other way to get the tool stored to X after AddTool(), by getting the pointer to it from GetId() or other means. None of these have worked though. There is FindById() and various other stuffs, but I think they are not implemented in wxLua, probably very new to wxWidgets too.



>Why not just pass the event to the DoThings function and get the info
>(like window id) from it inside the function? The les globals the
>better since it's less likely you'll accidently overwrite them.
>

I am VERY careful of my globals. >:) Thankyou though, I think you're right, but I don't see how. I have two event handlers firing, and one of them does as you suggest, but the one that tests the ControlDown() can't be calling the function if the other handler is doing it, so far as I know. The function would just get called twice, with no meaning. What I have is this:

FRAME:ConnectEvent(-1,wx.wxEVT_COMMAND_MENU_SELECTED,
    function(EV)  ID=EV:GetId()  DoThings(ID)  X=nil  end
)

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  if (EV:ControlDown()) then  X=1  end  EV:Skip()  end
)

If I could store that tool to a variable I could dispense entirely with that first event handler. This is why it's so useful. Although it could be said that overriding standard behaviour with mouse events is laborious, it's doable, and the increase in power and versatility makes it entirely worth doing.

>The wxToolbar is basicly a black hole, you only get the button pressed
>events back. I don't think there are ways to get the mouse events for
>the tools. That's why I suggested using wxButtons.
>

I live in hope. :) With FindById() and FindToolForPosition() it's clear that the black hole is evaporating nicely, but I guess that hasn't propagated to wxLua if it's a very recent change. Oddly, the FindToolForPosition() does appear to be in wxLua, but I still can't make it work. I guess the position has to be exact, and right now I don't know if it's screen based, or app window based. As ever, unless I see it work, it's pretty hard to derive anything useful from what I see.

I might try using all bitmap buttons, but I thing they suck, aesthetically, on a toolbar. :) What I'll probably do is what I already have, and shrink the blank toolbar space to prevent misfires. It's not a great answer, but it will definitely work.

Is it possible to GetId() for a mouse event? To get the ID of whatever the LEFT_UP happens on, and such? If so, this also would be an answer.

Crow.

Re: [Wxlua-users] ControlDown?

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

On 7/21/05, The Doctor <the...@bl...> wrote:
> Lastly, another question.. How would I make a tool, to be later added to =
a toolbar? I want to assign it to a variable so I can get direct access to =
mouse events on it. I've seen that tools can be added later, but nothing to=
 show how to make them in advance of this.

Instead of storing variables to your controls, you can get them from
the events. Try this.

    local toolBar =3D frame:CreateToolBar()
    toolBar:AddTool(100, bmp)
    bmpButton =3D wx.wxBitmapButton(toolBar, 101, bmp)
    toolBar:AddControl(bmpButton)
    toolBar:Realize()
   =20
    function bmpButtonHandler(event)
       local bmpButton =3D event:GetEventObject():DynamicCast("wxBitmapButt=
on")
       print(bmpButton) -- this is the button itself
    end
    bmpButton:ConnectEvent(101, wx.wxEVT_COMMAND_BUTTON_CLICKED,
bmpButtonHandler)


> My context:
>=20
> TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
>     function(EV)  if (EV:ControlDown()) then  DoThings()  end  EV:Skip() =
 end
> )
>=20
> In the above code, I can use DoThings() to set a global variable as a fla=
g, then test that flag during the handling for the tool, as this flag would=
 be set on ControlDown() for any toolbar click, whether on a tool or not. T=
his is awkward though, as I'll have to think of ways to reset that flag if =
anything else on the toolbar was clicked with the Ctrl key held. I added a=
=20

Why not just pass the event to the DoThings function and get the info
(like window id) from it inside the function? The les globals the
better since it's less likely you'll accidently overwrite them.

>ZZ=3DTBAR:AddTool(wx.wxID_SAVE...) but although ZZ exists, as userdata,
it's not the
>kind of userdata I need, I can't get an ID out of it, and such.. I
haven't even found out yet
>what ZZ actually is. :) I also tried replacing the -1 in the above
code with the ID of the
>button I wanted,

The wxToolbar is basicly a black hole, you only get the button pressed
events back. I don't think there are ways to get the mouse events for
the tools. That's why I suggested using wxButtons.

Regards,
    John Labenski

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(21/07/2005 18:37)

>I'm glad it helped, but sometimes a little more code would make the
>descriptions more clear. For example, what did you have that made the
>event:ControlDown() not work, maybe it was just a typo or something.
>


Sort of.. I had a wxEVT_COMMAND_BUTTON_CLICKED amongst the set of mouse events, and tried to make it work there, which it can't. I fixed it by making it a wxEVT_LEFT_UP and using Skip() afterwards to make sure the buttons worked right.


>> In other words, for a framework for adding an example, the easiest way that might help others as well as me might be to reach for whichever exiisting wxLua example is currently supplied with the distribution, and work it into that.
>
>That was what I was thinking.
>


What I forgot to add was the word 'you'.. :) If I'm not sure of something, it's quite possible I overlooked a context error, as in the most recent case. In that instance, the best correction would be for you to show the right working context. That was what was so valuable in your recent example. I usually catch my errors, but sometimes I get lost enough that after some hours I'll ask instead of thrashing around further.. I could show you my error, but I doubt that would be as useful as seeing the right method working. Besides, if I don't yet recognise my error this might be hard to do. :) In the last case I only realised it after seeing how your example worked.


>> I'm really hoping for wxLua to have libraries written so MIDI and audio signals can be handled. 
>
>That will be something you'll have to do unfortunately.
>


I don't know how. If I need to learn C I doubt I ever will. Also, if I had to get that deep into C that would sort of defeat the point of using wxLua.. :)


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


Lastly, another question.. How would I make a tool, to be later added to a toolbar? I want to assign it to a variable so I can get direct access to mouse events on it. I've seen that tools can be added later, but nothing to show how to make them in advance of this.

My context:

TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
    function(EV)  if (EV:ControlDown()) then  DoThings()  end  EV:Skip()  end
)

In the above code, I can use DoThings() to set a global variable as a flag, then test that flag during the handling for the tool, as this flag would be set on ControlDown() for any toolbar click, whether on a tool or not. This is awkward though, as I'll have to think of ways to reset that flag if anything else on the toolbar was clicked with the Ctrl key held. I added a control (bitmap button; as test, aesthetically it sucked), and that works as I want, but AddTool() doesn't seem to have any way to assign the tool to a variable while adding it. If it did, I could replace TBAR in the above code with that variable name, as I did for my test control button, solving the problem very neatly. I did try ZZ=TBAR:AddTool(wx.wxID_SAVE...) but although ZZ exists, as userdata, it's not the kind of userdata I need, I can't get an ID out of it, and such.. I haven't even found out yet what ZZ actually is. :) I also tried replacing the -1 in the above code with the ID of the button I wanted, but that doesn't work. The button works, but not the ControlDown bit. If I try wx.wxID_TOOLBAR it's very unhappy, says invalid ID. :) Can't help wondering what ID the toolbar is using if it's not that one, as that's what I assigned to it in the first place. Mystifying..

Thanks for the help, it's given me a day of useful effort, which is more than the previous session acheived.

Crow.

Re: [Wxlua-users] ControlDown?

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

On 7/20/05, The Doctor <the...@bl...> wrote:
> Thankyou. :)
> Sorry I didn't say something earlier, been a lot going on these past two =
days.

No, problem. We're all probably pretty busy.
=20
> That example you gave me will do well, I'll get something working from th=
at. The reason I didn't give a framework for code to be added to is that I =
don't often know what will be possible, as my question this time suggests.=
=20

I'm glad it helped, but sometimes a little more code would make the
descriptions more clear. For example, what did you have that made the
event:ControlDown() not work, maybe it was just a typo or something.

> In other words, for a framework for adding an example, the easiest way th=
at might help others as well as me might be to reach for whichever exiistin=
g wxLua example is currently supplied with the distribution, and work it in=
to that.

That was what I was thinking.

> I'm really hoping for wxLua to have libraries written so MIDI and audio s=
ignals can be handled.=20

That will be something you'll have to do unfortunately.

> PS. I did what you suggested, removed that SetEventHandler() stuff. I jus=
t bundled the individual handler code into a for loop. Can't help thinking =
though, that this might still fill up a load of RAM with dupes that might b=
etter be avoided with a bit of event propagation the user can control.

I don't think it'll be a problem, even with thousands of them.

Regards,
    John Labenski

Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

Thankyou. :)
Sorry I didn't say something earlier, been a lot going on these past two days.

That example you gave me will do well, I'll get something working from that. The reason I didn't give a framework for code to be added to is that I don't often know what will be possible, as my question this time suggests. I might think of two or three ideas and will usually only ask when something looks highly desirable and equally out of reach somehow. Also, I have no idea what supporting structure will be useful to you to get added to, as I don't know what will work, or I wouldn't be asking... and I could not offer anything that wasn't better provided by the examples that I got with wxLua. WHile I could give the precise content of my effort, that would be full of things you might not want to wade through, and if I later change my ideas based on your response, there's a likely chance I'd have wasted both of our time. :) I decided the best thing was to keep my question very simple and direct, and to trust you to know a working context that I could adapt once I saw it work, as will be possible with what you did for me here.

In other words, for a framework for adding an example, the easiest way that might help others as well as me might be to reach for whichever exiisting wxLua example is currently supplied with the distribution, and work it into that. This would be useful to others cos they can easily compare the old and new version of the example, and wouldn't have to wade through the specific details of my (probably very eccentric) code. Which is about ready for release, btw. What essentials remain are probably minor and easy to do, the extra delay was in handling the voice bank files, as I needed to integrate that into the existing stuff, and it wasn't as easy as I thought it might be. I rework a lot of stuff the more I learn, and the bigger a thing gets, the harder that is. It makes better modules though, so I'll try to write more once I do some other project for a while when this is done.

I'm really hoping for wxLua to have libraries written so MIDI and audio signals can be handled. Audio is useful for things like high-speed dataloggers and analog control inputs with high resolution, as well as audio itself. A sound card is a VERY useful I/O for stuff, if you remove the DC blocking capacitors. >:) That and MIDI will allow me to write some wxLua things that might get some strong interest in it, and encourage people to use it to test ideas for processing this kind of input, and customising other systems for music and laser work, and machine control. I can't write those libraries, I don't know C and like many, will be very keen (and grateful) to be able to focus on the things we need to model, without having to spend years doing something that isn't really where we want to go. My next task is to make a pitch to voltage converter, with high accuracy. If I could do this in digital domain, it will be so much better and more versatile than the anaolg circuit I'm going to have to learn to make..

/end ramble, just trying to keep the idea alive. :)

PS. I did what you suggested, removed that SetEventHandler() stuff. I just bundled the individual handler code into a for loop. Can't help thinking though, that this might still fill up a load of RAM with dupes that might better be avoided with a bit of event propagation the user can control.