Does anyone have any information about this phenomenon?  Is this a known problem, reported by other Mac users?  If so, how do my fellow Poser Python script-makers compensate for the problem?  Perhaps this is a Poser bug, or some oddity of this Mac user's OS environment? 

Any information at all would be helpful and appreciated.  :laugh:

I don't use often the spinctrl - I prefer using a wx.textctrl with a "charvalidator" function...

And I'm using a Windows OS most of the time... I have an iMac for testing. I'll take a look if I can reproduce this kind of error and if there is a soution for this :)

import poser
import wx
class test_dialog(wx.Dialog):
    def init(self):
        wx.Dialog.init(self, None)
       
        sizer = wx.BoxSizer()
        self.SetSizer(sizer)
        self.Fit()
       
        sctrl = wx.SpinCtrl(self, value="64", min=35, max=75, initial = 64)
        sctrl.SetMinSize((150, -1))
        sizer.Add(sctrl)
dlg = test_dialog()
dlg.ShowModal()

So I'm going to jump in and talk about this spin control. I do not like the buttons on the side, even when they appear in the correct location. They clutter the screen, and I never bother to push them. I want to use the mouse wheel.

The other thing I don't like is that they increment and decrement by a fixed amount. This is not the best approach for a Poser-related control. Whether it's the thickness of a prop, or the amount of bump in a shader, I like the click amount to be related to what's there already.

I have been working on my own custom control that does float numbers in increments that are self adjusting. It has no visible click buttons. It works with the wheel or the mouse pointer movement.

If your value is .004, a click up will add .001 and make .005.

If your value is 400, a click up will add 100 and make 500.

If you hold control, then the click amount is 1/10th the usual.

If you hold shift, the click amount is 2 times the usual.

I also made it so if you mouse down over the control and move your mouse up or down, that does the clicks as well. (Like an invisible vertical slider bar.)

I think it is a much better experience.

I am not completely done with debugging my implementation, but if you guys wanted to share and refine it with me, I'd be happy to work together with you and we all benefit from having a superior number editor for Poser work.

Maybe we could make some other specialty widgets as well.

I don't care for the arrow buttons, either, and I'm really not hung up on providing any equivalent to the arrow key functionality in any replacement widget.  I started using the SpinCtrl widgets because they were apparently the intended way to input integer values, and if I used them I didn't have to bother with valid type testing for the entry, as with the text widgets.  I can be sure the user has given me an integer, with these, and I don't have to worry that they're trying to pass off "Fred is a dog" as an integer, thus to snafu the script run and do who-knows-what to poor Poser in the process, since Poser seems to like to crash any time it gets even slightly confused, these days.  :unsure:  I'm gonna call this "type clamping", because Cage the Autodidact don't know them real, proper textbook terms for things.

I would like to have type clamping for float inputs, too.  Using a text entry for numerical inputs always bugs me.  Maybe it's just normal to do it that way in programming, and I just don't know that, with my limited frame of reference.  (Note that I do already apply entry type validity testing, when I use text entry fields for numerical entries.  I just like to use the built-in way to input the value, when possible.)

But right now I'm actually hoping to avoid replacing the use of SpinCtrl with anything else.  Two reasons.  One, I'm lazy, don't want to update two dozen scripts.  :lol:  Two, I don't have a website to allow distribution of updates, at this time.  I suspect this error reflects an oddity of the Mac user's OS environment.  Somethin' weird goin' on there.  No one else reports such problems, on the whole entire internet, as far as I can tell.

And, Tarim help me, I'm trying to blame the user.  Just like Customer Support keeps trying to do to me.  Oh, irony, why do you hate me so?  Why can't you be on my side, for a change?  Stupid irony.

Quote - Just tested... and it is working for me...

Thank you for the test, Semidieu.  :thumbupboth:  I've sent your test code to the user, to see if the same error crops up.  I'm not using a BoxSizer, which is the only noteworthy difference between your implementation and mine.  Maybe that's the key factor somehow.  :unsure:

I dream of a world where software doesn't come with loads and loads of bugs.  I dream of an apartment that fits the same criterion.  Ah, Cage is a foool, alas.  :lol:

Having some more Poser specific objects might be a good idea. The main problem will then to have a 'basic guide line' to make the objects 'similar' in the use.

Quote - So I'm going to jump in and talk about this spin control. I do not like the buttons on the side, even when they appear in the correct location. They clutter the screen, and I never bother to push them. I want to use the mouse wheel.

The other thing I don't like is that they increment and decrement by a fixed amount. This is not the best approach for a Poser-related control. Whether it's the thickness of a prop, or the amount of bump in a shader, I like the click amount to be related to what's there already.

I have been working on my own custom control that does float numbers in increments that are self adjusting. It has no visible click buttons. It works with the wheel or the mouse pointer movement.

If your value is .004, a click up will add .001 and make .005.

If your value is 400, a click up will add 100 and make 500.

If you hold control, then the click amount is 1/10th the usual.

If you hold shift, the click amount is 2 times the usual.

I also made it so if you mouse down over the control and move your mouse up or down, that does the clicks as well. (Like an invisible vertical slider bar.)

I think it is a much better experience.

I am not completely done with debugging my implementation, but if you guys wanted to share and refine it with me, I'd be happy to work together with you and we all benefit from having a superior number editor for Poser work.

Maybe we could make some other specialty widgets as well.

To provide some closure for the original question, it looks like SpinCtrl on OSX requires the use of a Wx sizer for proper display.  Without the sizer, weird things can happen.

Quote - self.divparm = wx.SpinCtrl(self, value="10",pos=(145,0), size=(50,20))

No sizer, bad.

Quote - sctrl = wx.SpinCtrl(self, value="64", min=35, max=75, initial = 64)
        sctrl.SetMinSize((150, -1))
        sizer.Add(sctrl)

Sizer, good.

Thanks for the feedback :)