wxlua-users Mailing List for wxLua

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

>sp:Connect(wx.wxEVT_KILL_FOCUS,
>    function(event)
>        print('k')
>    end)
>    

Thanks again for this, it works great.

I had to modify it to this:

for I=7,151 do
  CT[I]:Connect(wx.wxEVT_KILL_FOCUS,
    function(EV)  FeedBack(EV:GetId())  end
  )
end

...because I have a largish number of spinctrls (which is why it angers me that they fail as they do now, an entire program is ruined if I can't resolve this, it depends almost entirely on spinctrls!

If you have an equally neat trick to solve the spinctrl's habit of replacing text with the internal numeric value every time I hit the MAX or MIN limit, please show me. This is by far the more serious problem because the internal handling updates the display but does not send a signal! That means there is likely no simple way to prevent it doing this, except to detect any click as you showed in the first mail.

The problem with all this is that no matter how neat it is, that's now two functions, each connected to over 100 controls! This is NOT what people need, I thought the point of wxWidgets and wxLua was to enable fast easy building of programs, especially for those of us who don't know the depths behind the scenes. If I'm wrong about this, I doubt the control would ever have worked this way without this extra coding, but it did. All I ask (beyond any specific problem) is that it do so again, because instead of remembering basic use of a spinctrl I now have to keep a library of extra code just to get its original basic behaviour.

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

>sp:Connect(wx.wxEVT_KILL_FOCUS,
>    function(event)
>        print('k')
>    end)
>    

Thanks. That one's useful, it solves one problem. I could use it to restore the original text display. That still leaves a need to fix the lack of signal from the spinctrl if the value is not changed. That needs more than a mouseclick, it has to detect the area of each button, which gets so complex that I might as well display my own bitmaps and click on them, it would be easier! None of which is what I want! I'm asking merely that the wxSpinctrl works as it used to. It worked fine before, now it's broken and doesn't let us have signals to intercept to overcome its new limitations.

I think wxLua lets me make my own handler for events in another control, but even that won't help me if the event produces no initial signal at all.

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

>Lostgallifreyan <z.crow@...> writes:
>
>> 
>> Is there a way to tell a wxSpinctrl to always send a signal when a button is 
>clicked, not just when the value
>try
>
>this is a very long question I just try to anwer your 1st point.
>
>frame = wx.wxFrame(wx.NULL, wx.wxID_ANY,'')
>frame:Show(true)
>sp=wx.wxSpinCtrl(frame)
>sp:SetRange(23,37)
>
>sp:Connect(wx.wxEVT_LEFT_UP,  
>    function (event)
>        print('a')
>        event:Skip()
>    end)
>
>wx.wxGetApp():MainLoop()
>
>'a' is displayed on any click.
>

Thanks for the reply. I realise that I can do this, though I'd have to specify the exact relative area of each button so it knows which I clicked. That's a LOT of code, and as I cintend in my original mail, is a thorough defeat to the point of a spinctrl. Not only do I have to write code to override what cannot be overridden, am I now to have to write my own controls? THis doesn't only defeat the point of the spinctrl, it defeats the point of wxLua and wxWidgets. I turned to these because I did not know C, C++ and the Win32 API. Given how deep I have to go to overcome this, I'd have to take on a system that nullifies any need for wx-anything.

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

> 
try 

frame = wx.wxFrame(wx.NULL, wx.wxID_ANY,'')
frame:Show(true)
sp=wx.wxSpinCtrl(frame)
sp:SetRange(10,40)

sp:Connect(wx.wxEVT_LEFT_UP,  
    function (event)
        print('up')
        event:Skip()
    end)

sp:Connect(wx.wxEVT_KILL_FOCUS,
    function(event)
        print('k')
    end)
    
wx.wxGetApp():MainLoop()

You can enter any text in the control and focus does not change it.

Andre

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

> 
> Is there a way to tell a wxSpinctrl to always send a signal when a button is 
clicked, not just when the value
try

this is a very long question I just try to anwer your 1st point.

frame = wx.wxFrame(wx.NULL, wx.wxID_ANY,'')
frame:Show(true)
sp=wx.wxSpinCtrl(frame)
sp:SetRange(23,37)

sp:Connect(wx.wxEVT_LEFT_UP,  
    function (event)
        print('a')
        event:Skip()
    end)

wx.wxGetApp():MainLoop()

'a' is displayed on any click.

Is there a way to tell a wxSpinctrl to always send a signal when a button is clicked, not just when the value changes (is updated)? Also, is there a way to tell it NOT to replace a displayed text string with its lowest preset numeric value whenever focus departs or other inadvertent user event occurs?

What would be nice is two new 'styles' like ALWAYS_SIGNAL_EVENTS and NEVER_SELF_ADJUST, and as it's usually wise to use both, or neither, maybe just have one: EXTERNAL_HANDLING_ONLY. I looked at general window styles too, I can't find anything helpful for this problem there.

It used to work as I like it on wxLua v2.54 but since wxLua v2.8.something it seems that someone (at wxWidgets perhaps) broke what was otherwise nicely working. No doubt someone wanted it to 'correct' itself in case of invalid input, but this was a BAD move because it's not their call as to what displayed string is invalid. Filtering to reject non-numeric deliberate input is good, but displayed text is our business, not theirs. In case of bad entry, reversion to LAST good value would be nice, instead of LOWEST as is currently used, this being something I have seen others cry out for...

Sometimes we don't want a number displayed in a wxSpinctrl. For example, a musical scale transposition, while digitised as a number, is best displayed as a note value or tonal interval, the same logic might apply to a selection from a range of engineering threads or screw sizes. In this case the idea is to enter the number if you know it, otherwise select with buttons/arrow keys, all in a single control. This is no longer possible, which defeats the point of a spinctrl! The only way is to use two controls, a spinctrl sized to show only its buttons, and a textctrl to show the data. This fails to work well, not least because a nasty bug occurs! It the text ever exceeds the space to show it in the textctrl, the spinctrl's buttons get copied, redrawn as a functional ghost INSIDE the textctrl! (Functional as in you can click them, but no business results if you do, they just obscure text in the textctrl and cannot be dismissed once they appear. Also, if I want to click in the textctrl then use arrow keys or mousewheel to update the spinctrl I not only need two controls, but a lot of extra code! The whole point of the spinctrl, to combine the methods, is effectively ruined now. We might as well use the spinbutton (and textctrl) except that we're advised not to do so because spinbutton event signals aren't always available in some systems. If this degrades further, good things will not only be further broken, but perhaps taken away! Fat chance of encouraging anyone to write code if this happens... Rewriting a program to work on updated support is hard enough without having to work round breakages that used not to exist in earlier systems.

'Easy power'? Overcoming bugs like these is harder than learning C++ and the Win32 API which I now begin to regret not doing long ago. I tried inventing all kinds of workrounds for the failure in wxSpinctrl, setting wrap so it always updated with any click, adding 1 to MAX and -1 to MIN and clipping the fetched value myself with math.min() nested in math.max() and forcing update with the new value on the control manually after it sends a signal, and it still fails because it thinks no update occurred even when it had to have done, so all that results is the signal failure is displaced to the next button-click event! No matter what I try, I cannot overcome the bad internal handling. Even event(skip) fails to help here! If nothing else, THAT should always prevent self-'correction' so we can display our own text representations of its numeric value, but it doesn't. Even if it did, it doesn't allow us to get an update signal EVERY time either button is pressed so we can handle it as we want to.

I'm angry about this because all the coder's talk of RTFM and 'learn to code' means nothing. How can we accept being left in the dark, expected to code our own handlers for stuff, if we are barred from intercepting internal handling, or not even given a signal to handle at all when a deliberate event like a button click occurs?! What's worse is that IT USED TO WORK FINE. This isn't progress! This might not be the best place to rant, but I think it's as good as any. There are posts all over the net now complaining of breakages in wxSpinctrl, so I know it's likely not wxLua breaking it at all, but I might as well air this in a place I'm used to because it's not irrelevant here. Feel free to point wxWidgets coders this way (Gmane, or Mail Archive) if you know any, I think they seriously need to read this one.