Menu
▾
▴
wxlua-users
|
From: The D. <the...@bl...> - 2005-06-21 19:39:05
|
Just testing the mail for now, and saying I'm new to wxLua and I like it immensely. I'll turn over my project to help the cause, when it's done. To those who don't know the Yamaha DX7 synthesiser and the many compatible instruments made in the 22 years since, the Thinger will just be an extensive example of slightly eccentric wxLua coding, but to those who make electronic music, I hope it will be as useful to you as it already is to me. It's functional, emulates the original DX7's use of Init, Edit/Compare and Recall buffers, but I'm next to work on operator copy and algorithm display, and operations on 32-voice bank files. I'll release this as a full v1, when it's at least as fuctional as an FM synthesizer should be, I expect this to be in anything up to about 6 weeks time, but it might be a lot less. One bit of help I could use is some helpful comments regarding MIDI. This is a serial asycnchronous 31.25 Kbaud interface with 8 bits and a start/stop bit added to each byte, and a simple protocol with values over 127 as Status bytes, the rest as Data bytes, making it a useful machine control transmission with uses well beyone electronic music. This might excite someone into coding a library for wxLua. I hope. :) Right now I'm using a small German app called SysEx, which takes a command line, but I want something that doesn't pop up every time it's invoked. Last question: Is there anything (or will there be something) that can compile a wkLua script with all resources into a standalone binary? This would make wxLua more attractive than Visual Studio, to me. And probably to a few thousand other people, I suspect. To end: I'll add posts if I run out of ideas while working, begging for help, but I won't ask before I solve most things as I prefer it that way. Also, thans to John Labenski who has already helped a lot, and has helped launch this SourceForge effort, partly in response to my own wish that it might happen. Crow. PS. Small buglet? wxTextCtrl has rthe wrong system colour for text. There are at least two in MSwindows, and someone seems to have picked the wrong one. wxTE_RICH as style corrects this, but it would be nice to have it as default. :) |
|
From: John L. <jla...@gm...> - 2005-06-23 15:59:47
|
On 6/21/05, The Doctor <the...@bl...> wrote:
> Just testing the mail for now, and saying I'm new to wxLua and I like it =
immensely. I'll turn over my project to help the cause, when it's done. To =
those who don't know the Yamaha DX7 synthesiser and the many compatible ins=
truments made in the 22 years since, the Thinger will just be an extensive =
example of slightly eccentric wxLua coding, but to those who make electroni=
c music, I hope it will be as useful to you as it already is to me. It's fu=
nctional, emulates the original DX7's use of Init, Edit/Compare and Recall =
buffers, but I'm next to work on operator copy and algorithm display, and o=
perations on 32-voice bank files.
>=20
> I'll release this as a full v1, when it's at least as fuctional as an FM =
synthesizer should be, I expect this to be in anything up to about 6 weeks =
time, but it might be a lot less.
>
Let me be the first to say, welcome to wxLua. The app you're writing
sounds impressive, it'd be great to hear how things work or don't work
for you so we can patch up wxLua. There are so many components in
wxWidgets that it's impossible to test them all ourselves.
> One bit of help I could use is some helpful comments regarding MIDI. This=
is a serial asycnchronous 31.25 Kbaud interface with 8 bits and a start/st=
op bit added to each byte, and a simple protocol with values over 127 as St=
atus bytes, the rest as Data bytes, making it a useful machine control tran=
smission with uses well beyone electronic music. This might excite someone =
into coding a library for wxLua. I hope. :) Right now I'm using a small Ger=
man app called SysEx, which takes a command line, but I want something that=
doesn't pop up every time it's invoked.
I don't think anyone has any plans to implement this, but since this
is so specialized you're on your own in terms of what library to use.
We'd be happy to show how to write and implement wrapper for the lib
however.
=20
> Last question: Is there anything (or will there be something) that can co=
mpile a wkLua script with all resources into a standalone binary? This woul=
d make wxLua more attractive than Visual Studio, to me. And probably to a f=
ew thousand other people, I suspect.
This would be great, but this is probably going to be on the back
burner for awhile. Python can do it, so it must be possible.
> To end: I'll add posts if I run out of ideas while working, begging for h=
elp, but I won't ask before I solve most things as I prefer it that way. Al=
so, thans to John Labenski who has already helped a lot, and has helped lau=
nch this SourceForge effort, partly in response to my own wish that it migh=
t happen.
>=20
For very general wxWidgets questions you can even post to the wx-users
list. People will probably show you how to do things in c++ however,
but it can probably be translated.
=20
> PS. Small buglet? wxTextCtrl has rthe wrong system colour for text. There=
are at least two in MSwindows, and someone seems to have picked the wrong =
one. wxTE_RICH as style corrects this, but it would be nice to have it as d=
efault. :)
Humm, hopefully this will get sorted out in the next few weeks. We
can't test anything until the wrappers get fixed up though.
Regards,
John Labenski
ps. Please turn wordwrap on in your mailer, all your paragraphs come
out as extremely long lines.
|
|
From: The D. <the...@bl...> - 2005-06-25 19:30:55
|
John Labenski <jla...@gm...> wrote: (23/06/2005 16:59) > >Let me be the first to say, welcome to wxLua. The app you're writing >sounds impressive, it'd be great to hear how things work or don't work >for you so we can patch up wxLua. There are so many components in >wxWidgets that it's impossible to test them all ourselves. > Thankyou :) I stopped for a few days to do other things, heat and 99.9% humidity make foul conditions for thinking clearly... A couple of things came up in the last two days: One is wx.wxSYS_COLOR_HIGHLIGHT or any other system colour. I found I could specify wxColour(nnn,nnn,nnn), but I can't substitute any system colour, wxLua complains of an unexpected user defined data type if I try this. I also wonder if there are ever issues with color and colour. I've tested a couple in other contexts and found it will take either, which is cool. Another thing I haven't found a way to do is make a popup menu that appears if a button is clicked. I tried till I got confused, and all I can say is that nothing worked, and the variety of error reports was dazzling. :) > >I don't think anyone has any plans to implement this, but since this >is so specialized you're on your own in terms of what library to use. >We'd be happy to show how to write and implement wrapper for the lib >however. > That would help a lot. I haven't looked into MIDI libraries yet, but I certainly will, if I can't find a small SysEx file handler that doesn't work hidden. If this wrapper is something that can be written in Lua or wxLua I can learn this, though if it's C I prefer to stay away, because I found that learning C was too much, and is an all or nothing effort demanding too much detailed learning of the systems that support it. This why I turned to Lua in the first place. I can get things done without having to be a full-time programmer. >> Last question: Is there anything (or will there be something) that can compile a wkLua script with all resources into a standalone binary? This would make wxLua more attractive than Visual Studio, to me. And probably to a few thousand other people, I suspect. > >This would be great, but this is probably going to be on the back >burner for awhile. Python can do it, so it must be possible. > Good to hear. :) Python is quite large and complex, I've read, so wxLua having this ability would be a strong tool, and for many uses might be preferred by people who use both. |
|
From: John L. <jla...@gm...> - 2005-06-25 20:23:45
|
On 6/25/05, The Doctor <the...@bl...> wrote:
> A couple of things came up in the last two days:
> One is wx.wxSYS_COLOR_HIGHLIGHT or any other system colour. I found I cou=
ld specify wxColour(nnn,nnn,nnn), but I can't substitute any system colour,=
wxLua complains of an unexpected user defined data type if I try this. I a=
lso wonder if there are ever issues with color and colour. I've tested a co=
uple in other contexts and found it will take either, which is cool.
wx.wxSYS_COLOR_HIGHLIGHT (a number IIRC) is meant for wxSystemSettings.
local c =3D wx.wxSystemSettings.GetColour(wx.wxSYS_COLOR_HIGHLIGHT)
-- the above errors out since there's no constuctor for wxSystemSettings...
print("%d %d %d", c.Red(), c.Green(), c.Blue())
I think it's impossible to get at them since static methods aren't
handled properly. They need to be added to the wrappers as "LuaGlobal"
with a name of something like "wxSystemSettings_GetColour".
I'm sorry that we're deadlocked currently, I can't work on or test
this until we get a working wrapper system. Maybe another week or so.
> Another thing I haven't found a way to do is make a popup menu that appea=
rs if a button is clicked. I tried till I got confused, and all I can say i=
s that nothing worked, and the variety of error reports was dazzling. :)
local popMenu =3D wx.wxMenu()
-- add normal menu items
-- to position the menu for a button use local rect =3D
mybutton.GetRect() to find the bottom left.
mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY())
Regards,
John Labenski
|
|
From: The D. <the...@bl...> - 2005-06-25 21:07:32
|
John Labenski <jla...@gm...> wrote: (25/06/2005 21:22) > >> Another thing I haven't found a way to do is make a popup menu that appears if a button is clicked. I tried till I got confused, and all I can say is that nothing worked, and the variety of error reports was dazzling. :) > >local popMenu = wx.wxMenu() >-- add normal menu items >-- to position the menu for a button use local rect = >mybutton.GetRect() to find the bottom left. >mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY()) > >Regards, > John Labenski > Thankyou. I can't make that work though, even when it's spelled out like that. The mouseEvt's are nil values, so I substitute actual numbers, and that won't work either. If I take the PopupMenu instead of PopupMenuXY, and use a wxPoint instead of the two integers (as specified in the wxWidgets manual), that doesn't work either. I need something tested and verified. The problem I have is that if something works I can thrash around on my own trying to vary things to see what works, what breaks, and maybe even what will work better. If I can't get anything to work, all I can do is plead from a state of utter helplessness. Any actual working script, complete, no matter how small, is great, I can then take it apart til I know how it ticks. |
|
From: The D. <the...@bl...> - 2005-06-25 21:17:21
|
Belay that :) You had a . instead of a : in that code. The reporting didn't suggest that directly, but I wondered about it, and played with breaking a : to a . in some working code and got a similar error, so I tried the reverse here, and it fixed it. |
|
From: The D. <the...@bl...> - 2005-06-26 15:38:26
|
Hello, I've decided to try to use wx.wxEVT_LEFT_DCLICK and such to make specific mouse events for fast access to several things via a small number of controls, so that this access depends on motor memory as well as visual memory, this being very fast and easy to use. I've managed to make a single button (or even a static text label) be a control for this, so it's very versatile, but there is a major drawback: the window (control) must be assigned to a variable, and that means the event handlers proliferate in horrible tiers of duplication. With spin controls, it doesn't matter how many there are, or how many parent controls they're placed on, they're all captured by wx.wxEVT_COMMAND_SPINCTRL_UPDATED, but obviously I can't assign all my custom clickable controls to 'CC' to capture with CC:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff). Is there a way to group these assigned controls so a single event handler passes the flow to a single function which filters the controls by ID as usual? I've thought of making tables indexed by ID so that for loops can reduce the sixe of the source code, but this doesn't really solve the problem. |
|
From: John L. <jla...@gm...> - 2005-06-26 17:36:51
|
On 6/26/05, The Doctor <the...@bl...> wrote:
> Hello, I've decided to try to use wx.wxEVT_LEFT_DCLICK and such to make s=
pecific mouse events for fast access to several things via a small number o=
f controls, so that this access depends on motor memory as well as visual m=
emory, this being very fast and easy to use.
>=20
> I've managed to make a single button (or even a static text label) be a c=
ontrol for this, so it's very versatile, but there is a major drawback: the=
window (control) must be assigned to a variable, and that means the event =
handlers proliferate in horrible tiers of duplication. With spin controls, =
it doesn't matter how many there are, or how many parent controls they're p=
laced on, they're all captured by wx.wxEVT_COMMAND_SPINCTRL_UPDATED, but ob=
viously I can't assign all my custom clickable controls to 'CC' to capture =
with CC:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff).
I'm not sure I understand, all events are captured by your event
handler for wx.wxEVT_COMMAND_SPINCTRL_UPDATED?
In terms of easing the amount of duplicate code perhaps something like
this could work. (untested)
function CreateMySpinCtrl(parent, id, ...)
local win =3D wx.wxSpinCtrl(parent, id, ...)
win:ConnectEvent(id, wx.wxEVT_COMMAND_SPINCTRL_UPDATED, func)
return win -- return it for further processing if desired, ok if not us=
ed
end
> Is there a way to group these assigned controls so a single event handler=
passes the flow to a single function which filters the controls by ID as u=
sual? I've thought of making tables indexed by ID so that for loops can red=
uce the sixe of the source code, but this doesn't really solve the problem.
Are you saying that you cannot use the same function for two separate
win: ConnectEvent calls? I don't know of any reason why this shouldn't
work. Maybe you could post the simplest snippet of code that shows
your problem, just add a panel and two controls to the
VeryMinimal.wx.lua sample.
Regards,
John Labenski
|
|
From: The D. <the...@bl...> - 2005-06-26 17:53:00
|
The problem isn't the spincontrols. I only quoted those as an example of what works. The mouse event stuff is much less easy. Most of the mouse stuff seems to be absent, lots of things in the wxWidgets manual don't have any meaning in wxLua as far as I know. My specific problem is that I can't do FRAME:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff) and then make it work for anything I left click on the frame. If I have FRAME:ConnectEvent(-1,wx.wxEVT_COMMAND_SPINCTRL_UPDATED,DoStuff) I can put a spin control on a page on a notebook on a panel on a frame, and it will work. All spin controls will work, wherever they are. If I have FRAME:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff) ONLY the frame can be clicked! I must specify an exact one-to-one relationship for every control I want to click! I have 6 on each of three pages. Right now the required code will bulk to about 25% of all my active code because there is no way to sensible group the controls. I keep looking at it in stupefaction. Though I've found ways to make it work, it's a horrible kludge, and there seems to be no elegant way to do it. |
|
From: The D. <the...@bl...> - 2005-06-26 18:16:30
|
Here's an example. It will exit if the panel is double-clicked because wxEVT_LEFT_UP is explicitly linked to the panel, but the notebook isn't clickable, nor would any control on it be clickable unless it has its own explicit handling code. All I want is for wxEVT_LEFT_UP to be handled wherever it appears, and for my function to filter the event according to the ID of the control that produced the event. I've tested stuff to confirm that the ID is indeed passed, so this ought to work, and to be ideal. If it wasn't impossible...
If any toolbar button or menu entry works with wxEVT_COMMAND_MENU_SELECTED, and any button works with wxEVT_COMMAND_BUTTON_CLICKED, surely it makes sense to have any double-click of the left mouse button work with wxEVT_LEFT_DCLICK regardless of where in the area of a frame or dialog it happens. Separating the events by ID filtering is easy, so this would be the right way, given that it's fine for most other controls events. It might be arguable that there could be too many things to filter from, but I can't imagine why, there are only so many clicks per second the average human finger can do. :)
--=======================================================
FRAME=wx.wxFrame(wx.wxNull,-1,TITLE,wx.wxDefaultPosition,wx.wxSize(436,314))
PANEL=wx.wxPanel(FRAME,-1)
PAGES=wx.wxNotebook(
PANEL,
-1,
wx.wxPoint(11,30),
wx.wxSize(405,230),
wx.wxNB_TOP
)
PANEL:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
function(event) FRAME:Destroy() end
)
FRAME:Centre()
FRAME:Show(wx.TRUE)
--=======================================================
|
|
From: The D. <the...@bl...> - 2005-06-26 18:34:32
|
I've just been looking at the wxWidgets manual, at propagation, which appears to be the root of this business. It says only wsCommandEvent based events are propagated. As the word command appears in all the spin control, button, menu, events, I guess this is no co-incidence. How do I make sure that wxEVT_LEFT_DCLICK propagates all the way back to the frame? |
|
From: The D. <the...@bl...> - 2005-06-26 18:45:27
|
I've tried to get notice of whether the event should propagate by default. event:ShouldPropagate() This returns an error, invalid method. It has the same structure as event:GetId() which works fine, so being a simple thing I can't see what I could possibly get wrong. Does this mean that event:ShouldPropagate() doesn't exist in wxLua? And if control of propagation is missing, is there any way I can solve my mouse-click event problem? |
|
From: John L. <jla...@gm...> - 2005-06-26 18:56:40
|
On 6/26/05, The Doctor <the...@bl...> wrote:
> I've tried to get notice of whether the event should propagate by default=
.
>=20
> event:ShouldPropagate()
> This returns an error, invalid method.
>=20
> It has the same structure as event:GetId() which works fine, so being a s=
imple thing I can't see what I could possibly get wrong. Does this mean tha=
t event:ShouldPropagate() doesn't exist in wxLua?
Yes, this is a new thing in 2.6 IIRC, we'll add it. I don't think
it'll solve this issue, but I haven't tried it myself.
=20
> And if control of propagation is missing, is there any way I can solve my=
mouse-click event problem?
You need to call the frame handler directly,=20
FRAME:GetEventHandler():ProcessEvent(event). This is the wxWidgets
design since you don't want parent of windows getting confused/baraded
by mouse/key events from the children. If you do this make sure that
you assign valid IDs to each window so you can distinguish them in you
event handler using event:GetId().
I hope this helps,
John Labenski
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This seems to work as expected, you need to call FRAME:Close() not
FRAME:Destroy(). I added some other tests too.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FRAME=3Dwx.wxFrame(wx.wxNull,-1,TITLE,wx.wxDefaultPosition,wx.wxSize(436,31=
4))
PANEL=3Dwx.wxPanel(FRAME,-1)
PAGES=3Dwx.wxNotebook(
PANEL,
-1,
wx.wxPoint(11,30),
wx.wxSize(405,230),
wx.wxNB_TOP
)
PAGE1 =3D wx.wxPanel(PAGES, -1)
SPIN1 =3D wx.wxSpinCtrl(PAGE1, -1)
BUTTON1 =3D wx.wxButton(PAGE1, -1, "Press Me", wx.wxPoint(0, 30))
PAGES:AddPage(PAGE1, "Hello")
function HandleEvent(event)
SPIN1:SetValue(SPIN1:GetValue()+1)
end
PANEL:ConnectEvent(-1, wx.wxEVT_LEFT_UP, HandleEvent)
BUTTON1:ConnectEvent(-1, wx.wxEVT_COMMAND_BUTTON_CLICKED, HandleEvent)
PANEL:ConnectEvent(-1, wx.wxEVT_RIGHT_UP,
function(event) FRAME:Close() end
)
FRAME:Centre()
FRAME:Show(wx.TRUE)
|
|
From: The D. <the...@bl...> - 2005-06-26 19:32:01
|
I had a go with that code, but it doesn't solve the problem. What if I wanted to right-click that button? or double-click? Getting a standard button-click to call a common function isn't the problem, I can do that and have already used it in the Thinger script, as well as a careful set of valid ID's which is the foundation the whole thing rests on. I'll look into that FRAME:GetEventHandler():ProcessEvent(event) which looks likely enough, judging by the manual, though I can't yet follow it, it seems adrift without context so far... If you have a small but complete code that would be a great help to start. I'll try adding it to the ones I have but I doubt I can do it as fast or as easily as you can. Anything that works, even if it doesn't directly answer the need, is immensely useful, it is the fastest way I can learn from this, not least cos I like to play with it to see what else works and that gives me new answers to questions I might well never need to ask. Thanks for the Frame:Close() tip, I forgot that, either from something you said before, or something I found l;ast night and lost in an unsaved copy, and you just saved me some time finding it again. :) I can't remember where I bumped into that before but I tried it and it worked, and I found this morning that I didn't have it anymore. About propagation, I think it would solve this. The description of the process seems to indicate that it's exactly what I need, though anything that can link all types of mouse click to a single handler will do. |
|
From: The D. <the...@bl...> - 2005-06-26 19:44:06
|
Can I say Eureka?! I can say thankyou, anyway. the simplest answer is this: :SetEventHandler(PANEL) I append that to the code that sets up the button, then set the panel to handle the mouse clicks. I looked at your suggestion and basically decided to explicitly set the handler for any control I want to click in various amusing ways >:) Thanks again, I doubt I'd have got there on my own. Crow. |
|
From: The D. <the...@bl...> - 2005-06-26 20:10:14
|
Last questions for the day... If I make it so a right click and a right double-click call different functions (in this case showing a message box as a test flag with different text on it), the double click won't work, only the right click. Either works alone, but the right-click takes priority. It looks as if it won't wait long enough to establish whether a second click occurs, basically. Is there an easy way to make it so both types can work? Also, might I need to use event:skip() to override the default action of a button if I find apparent confilcts with standard left clicks? |
|
From: The D. <the...@bl...> - 2005-06-26 22:09:43
|
I've just seen my first wxLua crash. WXLUA caused a stack fault in module WXMSW254_VC_WXLUA.DLL at 016f:100d10eb. Registers: EAX=1058adb8 CS=016f EIP=100d10eb EFLGS=00010216 EBX=008afa06 SS=0177 ESP=007b1fd4 EBP=007b2000 ECX=ffffffff DS=0177 ESI=00008a2a FS=18bf EDX=00000000 ES=0177 EDI=008af9bc GS=0000 Bytes at CS:EIP: 89 4d f8 8b 55 08 8b 42 04 89 45 fc 83 7d f8 ff Stack dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 007b202c 100d072a 1058adb8 00efa400 007b2074 It happens consistently, as a result of using X:SetEventHandler(PANEL), where X is a button or other control whose event handling is set elsewhere for common handling of mouse clicks. The program is running ok as far as I know, until the crash is invoked by changing the OS colour scheme. (I discovered this while changing it to see the effects of using wx.wxNullColour.) I commented out all the new code to eliminate things until the bug didn't happen, then looked at what addition would alone be enough to cause the crash when the OS scheme was changed, and it's definitely that X:SetEventHandler(PANEL) bit. Even with NO code affecting colours by explicit demand, this happens. |
|
From: John L. <jla...@gm...> - 2005-06-26 23:41:13
|
On 6/26/05, The Doctor <the...@bl...> wrote:
> I've just seen my first wxLua crash.
>=20
> WXLUA caused a stack fault in module WXMSW254_VC_WXLUA.DLL at 016f:100d10=
eb.
Oops. :(
> It happens consistently, as a result of using X:SetEventHandler(PANEL), w=
here X is a button or other control whose event handling is set elsewhere f=
or common handling of mouse clicks. The program is running ok as far as I k=
now, until the crash is invoked by changing the OS colour scheme. (I discov=
ered this while changing it to see the effects of using wx.wxNullColour.) I=
commented out all the new code to eliminate things until the bug didn't ha=
ppen, then looked at what addition would alone be enough to cause the crash=
when the OS scheme was changed, and it's definitely that X:SetEventHandler=
(PANEL) bit. Even with NO code affecting colours by explicit demand, this h=
appens.
I don't think your SetEventHandler(otherWindow) trick will work
without some serious c++ testing.You're probably breaking the chain of
handlers, hence the segfault. However, you may want to explore
PushEventHandler, but I bet you have to Pop it before the window is
destroyed.
What you're doing sounds a little strange, it doesn't make sense to
get the left button press on a wxButton, just get the
wx.wxEVT_COMMAND_BUTTON_CLICKED or if you want to disable the button
use button:Enable(false). Remember, wxWidgets wraps around the native
library and if that doesn't provide a function, neither does wxWidgets
(but they do try to smooth things out as much as possible). I would be
pleasantly surprised if a wxButton emitted a left down event for
example.
In terms of double clicks, it's always down, up, double IIRC.
Finally, FRAME:GetEventHandler():ProcessEvent(event) merely takes the
event you get in a child window, so you've got to set a handler for
it, and then asks the FRAME to handle it as if it was meant for it
(you're on your own doing this for key and mouse events since
wxWidgets may use them as well for some controls and won't expect them
from child windows). It would be best to simply call a common function
to handle the event for all windows if this is what you really want.
Good luck,
John Labenski
|
|
From: The D. <the...@bl...> - 2005-06-27 08:58:57
|
Todays work will be to try PushEventHandler instead of SetEventHandler, as I read that it was preferred. I just stayed with what appeared to work so far, and also to test what was possible. :) The override of the button left click was just a matter of testing, I got it with event:Skip() before my own call, placed in the EVT_LEFT_UP handler. I removed the original BUTTON_CLICKED handler... This probably won't be my final answer; I was considering the StaticText, but that won't take a colour change so it can't be used as an indicator. Disabling is not an option, as I need the control to be enabled regardless of its state. I'm just trying stuff to see what can work, before I settle on the best choice. About the LEFT_UP before DCLICK, I agree, I overlooked for a moment that LEFT_UP must always be detected during a DCLICK, and there seems to be no way to separate them. In this case it will be acceptable though, as the stuff ordered by LEFT_UP is small, fast, and there is no harm in it being done also when DCLICK orders its own stuff. I'll try to separate the orders some time, but it's not a high priority now. Your point about being pleasantly surprised if a wxButton gives a LEFT_DOWN is exactly the same sort of thing that drove me to this experiment. I want to find a reliable way to get any kind of click I might want from a control. That way I can make more events from one control. It makes motor memory play a bigger part instead of the current high reliance on visual memory. Doing this increases the ease and efficiency of moderately complex user operations, as well as allowing only those methods required to do the task. For example: in my taks I want a control to do a data copy on left click, to toggle a state with double-click, indicating said state on the same control, and to popup a menu of paste options with the right click, all on the same control. I have achieved this, but not yet found the best way, no doubt... I was partly hampered by the alternate bitmaps and toggling not working in wxLua toolbar buttons. :) This made me look for other options... I've now decided that I want this rather badly, the idea of being able to use any or all kinds of mouse click for a single control of many or even all types, is so powerful, to me it makes sense that it should be possible, easily overriding a default behaviour where needed. Btw, about FRAME:Close(), I remember why I didn't keep it that way now. I tried it again after your mail. I have a handler to catch any attemt to close the frame. It does stuff, then FRAME:Destroy(), cos FRAME:Close() in that handler makes a loop until some stack overflows. :) If there is a better way to avoid that loop, please let me know. > It would be best to simply call a common function > to handle the event for all windows if this is what you really want. It is. But that's the problem. For SpinCtrl's I do this easily, I just use FRAME:ConnectEvent() for wxEVT_COMMAND_SPINCTRL_UPDATED to catch them all and call a function that processes according to ID. This works cos the COMMAND events propagate right back to the frame. While the mouse LEFT_UP, DCLICK and such do not propagate, I have to catch each control I want to click by using a handler for each one, each handler calling the common function. That's a lot of code, even for 3 groups of 6 buttons on separate notebook pages. If I could make some tiny, hidden control with no events of its own, say a StaticText of zero display size, I could make all the click events get handled by that. I'd still have to direct the handling from each real control, but at least the code to do it is very small and neat. I guess what I'll do is turn over the Thinger before it's complete, so you can see what is being done. I just want to make sure it works as intended, so that the behaviour as seen by the user is clear, and then any code corrections will be easier to do, as there will be a working precedent for what it has to do. Having got the main idea for Operator parameter copying and output enabling sussed (or at least doable), it shouldn't be long now. I suspect a lot will be better changed, but I think we'll get more out of it this way. I'll learn more easily about better coding from modifications to work I've already done, and you'll see an idea that might make some interesting ways to do things, and one that demonstrates what I feel is a need for easier customising of control handling. |
|
From: The D. <the...@bl...> - 2005-06-29 18:08:34
|
I tried PushEventHandler yesterday, and it caused a crash before the program showed anything on screen. I also tried SetEventHandler to make a StaticText handle all messages, and also making one button handle all of the messages from the others, and each test failed. The one thing that has worked is using SetEventHandler to the frame or the panel on it, I've not tried other things. I've done the code for operator copy and paste, and individual output muting, and the whole program flow is better. I'll try to get two last major things I want to add, then hand it over so people can see what is happening. I'm hoping that wxLua will have some way to customise routes for event handling. As I said in a very recent mail, this will be extremely useful, at least to me.. |
|
From: John L. <jla...@gm...> - 2005-06-29 21:13:12
|
On 6/29/05, The Doctor <the...@bl...> wrote: > I tried PushEventHandler yesterday, and it caused a crash before the prog= ram showed anything on screen. I also tried SetEventHandler to make a Stati= cText handle all messages, and also making one button handle all of the mes= sages from the others, and each test failed. The one thing that has worked = is using SetEventHandler to the frame or the panel on it, I've not tried ot= her things. I'm sorry that all that is untested, at least by me. I guess I still don't understand why you don't want to just what's below, which is known to work and would seem to me to be simplier. Swapping out event handlers is not to be taken lightly, you really have to check out what going on when you do things like that. See here for what happens when you push/pop a handler. http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/common/wincmn.cpp?rev=3D= HEAD&content-type=3Dtext/vnd.viewcvs-markup search for: void wxWindowBase::PushEventHandler(wxEvtHandler *handler) Try doing this instead. function HandleButtonLeftUpEvent(event)=20 if event.GetId() =3D 1 then do stuff... else if event.GetId() =3D 2 then=20 ... end function MakeMyButton(parent, id, ...)\ local button =3D wx.wxButton(parent, id, ...) button:ConnectEvent(-1, wx.wxEVT_LEFT_UP, HandleButtonLeftUpEvent) button:ConnectEvent(-1, wx.wxEVT_RIGHT_UP, HandleButtonRightUpEvent) etc... return button end All you have to do to create a button is then MakeMyButton(PANEL, 10, ...) MakeMyButton(PANEL, 11, ...) |
|
From: The D. <the...@bl...> - 2005-07-05 00:30:07
|
Sorry, was an error with its parenting... :) Anyway, the Thinger will be ready in a few days at most now. |
|
From: The D. <the...@bl...> - 2005-07-05 00:23:43
|
Hi John, is the wxEVT_COMMAND_RADIOBUTTON_SELECTED working? I can't get any kind of response out of that at all. |
|
From: John L. <jla...@gm...> - 2005-07-05 00:43:11
|
On 7/4/05, The Doctor <the...@bl...> wrote:
> Hi John, is the wxEVT_COMMAND_RADIOBUTTON_SELECTED working? I can't get a=
ny kind of response out of that at all.
It seems to work here, maybe you want wxEVT_COMMAND_RADIOBOX_SELECTED?=20
Regards,
John Labenski
|
|
From: The D. <the...@bl...> - 2005-07-09 18:31:32
|
I've thought of something useful, but I don't know if it can be done. First, the reason for asking... I can disable a set of controls by wx.wxEnable(nil) on a parent window, but this changes the appearance, often in ways I do not want. Or, I can make a dialog overlay that is transparent, but this only works in Windows, and I'd have to find ways to prevent tabbing and scrollwheels from affecting the masked controls. I decided that the best answer might be to use a control that fools transparency by opying the area under the control, as it is made, so it is an image layer that appears to be transparent. There are four advantages: 1. I can disable the group window underneath after the new control is displayed, so the appearance is retained as if there was an active set of controls. 2. As it doesn't need real transparency, it could more likely be platform independent. 3. The disabling of the real surface underneath means that there is no chance of a masked control being interfered with. 4. I can disable or otherwise change singular aspects of the control surface in the moment before the layer mask is shown, and then disable the whole underlying surface. This can give a lot of control over how the disabled controls are displayed in the masking window. Please can you tell me if this is doable? In effect it must be a display of a screenshot of the relevent area, made the moment before it is displayed as a layer masking the real surface. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X