wxlua-users Mailing List for wxLua

Lostgallifreyan <z....@bt...> wrote:
(31/12/2010 16:23)

>SC:Connect(-1,wx.wxEVT_SCROLL_THUMBTRACK,DoStuff)  -- Where SC is a SpinCtrl. That's it! Do this instead of SPINCTRL_UPDATED, and it works.
>
>What's even more amazing is that this removes the need for the KILL_FOCUS correction too, it totally restores SpinCtrl to the behaviour it used to have with wxEVT_COMMAND_SPINCTRL_UPDATED in wxLua v2.54, it appears to be an exact substitute.
'
'
'
>Whether anyone cares enough to trust any of my code as a partial basis for worked examples is something I doubt, but I will hand it over if you want it. I'm willing to spend some time reducing several things I've done to minimal demonstration scripts, if the effort is not wasted. I'm not the most knowledgebale, but I am persistent enough to come up with answers, and I think wxLua maybe needs all the help it can get, there aren't a lot of people around...

Ok, I was wrong about that KILL_FOCUS point, but I have worked out an example of an array of symbolic SpinCtrls that might be a useful inclusion to the example scripts:



function Main()
  FRAME=wx.wxFrame(wx.NULL,-1,"")
  FRAME:SetTitle("Symbolic SpinCtrl Array")
  PANEL=wx.wxPanel(FRAME,-1)
  IDS=wx.wxID_HIGHEST+1                                                         -- IDS is 'ID Start', first ID of safe range unused by system.
  NT={"One","Two","Three","Four","Five",                                        -- Creates a table of text representations to assist user input.
    "Six","Seven","Eight","Nine"
  }  NT[0]="Zero"
  SC={}
  for N=1,4 do  local ID=IDS+N
    SC[N]=wx.wxSpinCtrl(PANEL,ID,"",wx.wxPoint(N*62-60,2),                      -- Physical placement arithmetic done here to keep it simple.
      wx.wxSize(60,20),wx.wxSP_ARROW_KEYS+wx.wxTE_PROCESS_ENTER,0,9,0           -- Note two 'styles' to enable arrow keys and direct text entry.
    )
    SC[N]:Connect(ID,wx.wxEVT_SCROLL_THUMBTRACK,FeedBack)                       -- Acts as wxEVT_COMMAND_SPINCTRL_UPDATED once did, ALWAYS signals!
    SC[N]:Connect(ID,wx.wxEVT_COMMAND_TEXT_ENTER,FeedBack)                      -- Required, as is wxTE_PROCESS_ENTER, to enable direct number entry.
    SC[N]:Connect(ID,wx.wxEVT_KILL_FOCUS,NoOp)                                  -- Prevents de-focus replacing text with lowest preset number value.
  end
  FRAME:SetSize(258,51)  FRAME:Centre()  FRAME:Show()
end

function FeedBack(I)
  if type(I)=="userdata" then  I=I:GetId()-IDS  end                             -- This test allows the function to be passed an event OR an index.
  SC[I]:SetValue(NT[SC[I]:GetValue()])                                          -- Fetches value, indexes symbolic text to replace it for user display.
end

function NoOp()  end                                                            -- Does nothing! Called to prevent unwanted inbuilt event handling.

Main()

Andre Arpin <ar...@ki...> wrote:
(31/12/2010 21:07)

>note given: text = wx.wxTextCtrl(...
>then
>
>v = text.Value
>v = text[Value]
>v = text:GetValue()
>v = text.GetValue(text)
>
>are all equivalent
>

Which is nice but I'd hoped it cut both ways. :) Sadly, while EV.Id neatly replaces EV:GetId(), you can't do SC.Value=SC.Value.."text" to force text replacement in a SpinCtrl derived directly from its own value, but you CAN do it with SC:SetValue(SC.Value.."text"). I guess I can either use the dot for reading but not writing, or stay with Set and Get for symmetry... Both approaches seem useful to me.

Lostgallifreyan <z.crow@...> writes:

> That's my problem, remembering rules is hard without understanding, and this 
goes deeper than I know how to
> go. Even 'syntactic sugar', which I have often seen mentioned, confuses me, 
but I take it to mean a way of
> easing the readability of code that associates values, functions, with each 
other. If so, I'm all for it
> because I chose Lua because I can read it, think it, as I do with spoken 
language, and this is impossible with
> C, at least for me... The practical question is: which constructs in a 
language as alive and mutable as Lua
> (wxLua, wxWidgets) will remain archetypal? Some basics need to be consistent 
in the long term, or we will
> be forever rewriting our code just to catch up with new Lua or wxLua 
releases. This, more than anything,
> drives me to ask questions instead of being able t
>  o find out stuff for myself (which I do at least 95% of the time anyway). 
The more of these method remain in use
> the better; freedom does matter, I agree.
> 

The . : notation is well embedded into Lua. The extensions to wxlua of the . 
notation is to present more a c++ flavour (so I think) to wxlua. 
This is a more elegant notation and perfectly suited to Lua as well.

On the other hand Lua extend it's notation with a . for table more syntactic 
sugar. (Programming languages are bad for diabetic.)

In Lua a.b === a['b'] where a.b is a very welcome extention.

Also a:f(...) === f(a, ...) wxlua make extensive use of this extension as well.

I do not expect this syntax to ever change in the future.

Andre

note given: text = wx.wxTextCtrl(...
then

v = text.Value
v = text[Value]
v = text:GetValue()
v = text.GetValue(text)

are all equivalent

Andre Arpin <ar...@ki...> wrote:
(31/12/2010 00:11)

>
>Lostgallifreyan <z.crow@...> writes:
>
>> 
>> Small syntactic question...
>> Andre's code in another thread used a dot, the results are neater than the 
>colon I learned to use....
>> 
>> ST:SetLabel(SC:GetValue()
>> ST.Label=SC.Value
>> 
>> I imagine this is an old issue so I'll keep this short:
>> Is one of these methods to be deprecated (made obsolete), and if so, which?
>> 
>> Ok, one more question:
>> Is there a case where the two methods are NOT equivalent, and if so, what?
>
>The . is valid but a trick within wxlua. 
>Get..., Set... are supported.
>

I should have known there was no simple answer to a deceptively simple question. :) Such is code...
Is the dot notation also valid in Lua too? I suspect it is, but I need to know if it might likely stay that way. I like your way of writing it, so I'll try it to see how far I can take it without breaking stuff.

>Set/GetValue become var.Value = or Foo = var.value
>als note that Is is magic so 
>ww = wx.wxTopLevelWindow ...
>then ww.IsActive  works 
>Ok and Eof are also magic, sor var.Ok is useful
>

I recall that Lua's flexibility with naming things is extreme, I saw an example where Henry=print and so forth, so you could Henry("stuff") to the screen and the madness didn't end there either. >:) I take it this flexibility is partly what allows these alternative notations too?

>Now var.Value is resolved in 2 steps (only the first time).
>
>resolution...
>The index fail within the meta (either index/newindex)
>
>Now the argument must be single for the following to happen.
>The index is added to the object, the code is rerun and now works. 
>In all subsequent call the index allready exist and this all works.
>There is a small cost time and space.
>
>This is syntactic sugar like 
>function Foo(arg) etc     in lua
>is 
>Foo = Function(arg) etc 
>
>Most language and system supports these type of things.
>I find it more readable and I like it, other may not. 
>
>Its a free world (sometime).
>
>Andre
>
>PS: I have rewritten the Lua editor to suggest all these variances by using 
>the dynamic binding support. So to me it is easy to use otherwise you have to 
>remember all the rules.
>

That's my problem, remembering rules is hard without understanding, and this goes deeper than I know how to go. Even 'syntactic sugar', which I have often seen mentioned, confuses me, but I take it to mean a way of easing the readability of code that associates values, functions, with each other. If so, I'm all for it because I chose Lua because I can read it, think it, as I do with spoken language, and this is impossible with C, at least for me... The practical question is: which constructs in a language as alive and mutable as Lua (wxLua, wxWidgets) will remain archetypal? Some basics need to be consistent in the long term, or we will be forever rewriting our code just to catch up with new Lua or wxLua releases. This, more than anything, drives me to ask questions instead of being able to find out stuff for myself (which I do at least 95% of the time anyway). The more of these method remain in use the better; freedom does matter, I agree.

Thankyou. It ran, but it was something in your code that led to the answer, and this time it really IS the answer:

SC:Connect(-1,wx.wxEVT_SCROLL_THUMBTRACK,DoStuff)  -- Where SC is a SpinCtrl. That's it! Do this instead of SPINCTRL_UPDATED, and it works.

What's even more amazing is that this removes the need for the KILL_FOCUS correction too, it totally restores SpinCtrl to the behaviour it used to have with wxEVT_COMMAND_SPINCTRL_UPDATED in wxLua v2.54, it appears to be an exact substitute.

It was your use of EVT_SCROLL_LINEUP (and DOWN) that led me there.
First, I tried my own SpinButton code, and that failed because SpinButton has its own breakage! Fails to use SP_ARROW_KEYS. Never mind what the docs say, it doesn't work, nor does the mouswheel which works by default with that style (in SpinCtrl anyway). But I also read that some (not all) of the SpinButton events are also used (on some platforms) by SpinCtrl. I hunted online for any worked example of event handling in SpinButton beyond yours, because there is none in the sample scripts! I found my answer on some list of events, but I had no idea if it would work till I tried it.

At times I despair of documentation! For example wx.chm states that EVT_SPINCTRL is handled. Well it isn't, if you write that you just get an error, you have to write wxEVT_COMMAND_SPINCTRL_UPDATED if you want that to work! This isn't an example of transparent clarity! Worse, wx.wxEVT_SCROLL_THUMBTRACK isn't named at all in this context, and given what its name IS, it's hardly surprising that most users would have no clue that it will work. Which means we have NO idea if it will still work later if (hopefully when) someone cleans this up! Or if someone breaks the inbuilt scrollwheel link with SpinCtrl, as seems to be the case with SpinButton already, if it ever had one.

I love wxLua, I really do, it's let me do more than any other system so far, but at times like these I wonder if it isn't a cloud of nonsense between me and the API that I'd do better to blow aside completely. The naming, linking, and conventions of event handling seem especially loose and uncoordinated. This is really a case where ONLY a solid body of worked examples will do, documentation is NEVER enough. Only established practise is going to lock this down.

Whether anyone cares enough to trust any of my code as a partial basis for worked examples is something I doubt, but I will hand it over if you want it. I'm willing to spend some time reducing several things I've done to minimal demonstration scripts, if the effort is not wasted. I'm not the most knowledgebale, but I am persistent enough to come up with answers, and I think wxLua maybe needs all the help it can get, there aren't a lot of people around...

Ok, I ranted again, but I think I earned the right to a little excess, given that this mail does include the kind of answer that we need, very small, very effective, as it gives a signal every time an attempt is made with SpinCtrl, instead of taking from us the right to decide what events matter.



Andre Arpin <ar...@ki...> wrote:
(30/12/2010 23:35)

>I hope this version will run
>
>“strict” is a popular module used to prevent  leaky variables, most useful.
>
>This code emulates the spin control and should make it easier to support your 
>variations. I hope it works. I just shorten the lines. Line are not properly 
>broken and probably should be adjusted for clarity.
>
>local baseID = wx.wxID_HIGHEST + 1
>
>textControls = {}
>frame = wx.wxFrame(wx.NULL, 
>wx.wxID_ANY,'Test spin control')
>frame:Show(true)
>
>function spin(event)
>    local localSpin = event:GetEventObject():
>    DynamicCast("wxSpinButton")
>    print(localSpin.Value)
>    print(event.Id)
>    textControls[event.Id - baseID + 1][1].Value =
>    tostring(localSpin.Value)..'!'
>end
>
>function text(event)
>    print(event.KeyCode)
>    event:Skip()
>    local localText = event:GetEventObject():
>    DynamicCast("wxTextCtrl")
>    local v = tonumber(localText.Value)
>    print(v)
>    if v then
>        textControls[event.Id - baseID + 1][2].Value = v
>    end
>end
>
>for ID= baseID, baseID + 10 do
>    local top = 30*#textControls
>    local textControl = 
>    wx.wxTextCtrl(frame, ID, 'test', wx.wxPoint(20,top))
>    local spinControl = 
>    wx.wxSpinButton(frame, ID, wx.wxPoint(0,top))
>    table.insert(textControls, {textControl, spinControl})
>    spinControl:SetRange(10,20)
>    spinControl:Connect(wx.wxEVT_SCROLL_LINEUP, spin)
>    spinControl:Connect(wx.wxEVT_SCROLL_LINEDOWN, spin)
>    textControl:Connect(wx.wxEVT_KEY_DOWN, text)
>    
>end
>
>wx.wxGetApp():MainLoop()
>
>Good luck.
>
>Andre
>
>
>------------------------------------------------------------------------------
>Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>to consolidate database storage, standardize their database environment, and, 
>should the need arise, upgrade to a full multi-node Oracle RAC database 
>without downtime or disruption
>http://p.sf.net/sfu/oracle-sfdevnl
>_______________________________________________
>wxlua-users mailing list
>wxl...@li...
>https://lists.sourceforge.net/lists/listinfo/wxlua-users

Lostgallifreyan <z.crow@...> writes:

> 
> Small syntactic question...
> Andre's code in another thread used a dot, the results are neater than the 
colon I learned to use....
> 
> ST:SetLabel(SC:GetValue()
> ST.Label=SC.Value
> 
> I imagine this is an old issue so I'll keep this short:
> Is one of these methods to be deprecated (made obsolete), and if so, which?
> 
> Ok, one more question:
> Is there a case where the two methods are NOT equivalent, and if so, what?

The . is valid but a trick within wxlua. 
Get..., Set... are supported.

Set/GetValue become var.Value = or Foo = var.value
als note that Is is magic so 
ww = wx.wxTopLevelWindow ...
then ww.IsActive  works 
Ok and Eof are also magic, sor var.Ok is useful

Now var.Value is resolved in 2 steps (only the first time).

resolution...
The index fail within the meta (either index/newindex)

Now the argument must be single for the following to happen.
The index is added to the object, the code is rerun and now works. 
In all subsequent call the index allready exist and this all works.
There is a small cost time and space.

This is syntactic sugar like 
function Foo(arg) etc     in lua
is 
Foo = Function(arg) etc 

Most language and system supports these type of things.
I find it more readable and I like it, other may not. 

Its a free world (sometime).

Andre

PS: I have rewritten the Lua editor to suggest all these variances by using 
the dynamic binding support. So to me it is easy to use otherwise you have to 
remember all the rules.