wxPython 4.0.3 NewId confusion

[rolfofsaxony]

May be I missed the reason that NewId was given its marching orders into the dustbin of history but I am a loss as to why something used by so many, in so much code, which will involve so much code checking and testing has been changed.

Loading up 4.0.3 I now have

wx.NewId() - no deprecated warning and still working happily

wx.NewIdRef().GetId() - A high negative number incrementing towards 0

wx.Window.NewControlId() - which looks like a reference to wx.NewRefId

Given that NewId still works and does not issue a deprecation error, I am safe to keep using it or will it stop working in the future with the same ruthlessness that it joined the culled group of commands? If so, which of the 2 new options should I use as a drop in replacement?

The issue that I have with NewRefId is that it is negative, so when one creates a Bind command that utilises by "id" and "id2"

such as

self.Bind(wx.EVT_MENU, self.OnAutoTimeStamp, id=TIMESTAMP_OFF,id2=TIMESTAMP_COMMENT)

previously, using NewId one got positive numbers that worked smoothly with this feature.

Now the Id's have to be assigned backwards because of the negative number issue, it is counter intuitve.

Rant Over!

Regards

Rolf  

[Robin Dunn]

On Thursday, June 28, 2018 at 7:34:26 AM UTC-7, rolfofsaxony wrote:

May be I missed the reason that NewId was given its marching orders into the dustbin of history but I am a loss as to why something used by so many, in so much code, which will involve so much code checking and testing has been changed.

There was a bunch of discussion about it in this thread: https://groups.google.com/d/msg/wxpython-users/QjNaxW0R7uc/q8OHgXYTBQAJ The nutshell version is that it is possible for IDs returned by wx.NewId to conflict with manually assigned IDs (like ID_A=5001; ID_B=5002; ...) which is still a common thing in wx C++ application code. And also since there is no management of IDs returned by wx.NewId then it can even conflict with itself if the counter wraps around.

OTOH, the new system (which has been used internally in wxWidgets for a while now) for automatically assigned IDs keeps track of the auto-assigned IDs so they can't conflict with other auto-assigned IDs which are still active.

 

Loading up 4.0.3 I now have

wx.NewId() - no deprecated warning and still working happily

I think that whether you see the warning by default can depend on Python version, platform, environment and what mode Python is running in. Resetting the warnings filter will make them visible again. For example:

>>> import wx

>>> wx.NewId()

100

>>> import warnings

>>> warnings.simplefilter('default')

>>> wx.NewId()

__main__:1: DeprecationWarning: NewId() is deprecated

101

>>>

 

wx.NewIdRef().GetId() - A high negative number incrementing towards 0

wx.Window.NewControlId() - which looks like a reference to wx.NewRefId

wx.Window.NewControlId() simply returns the next integer in the sequence, and it is the same thing used inside wx.NewIdRef and also when you create a widget/timer/whatever with a wx.ID_ANY or -1 ID. When it is assigned as the widget's ID then it goes into a wxWindowIDRef member which releases the ID when it is destroyed if the refcount drops to zero. That is also the same thing that happens inside wx.NewIdRef, except you get to manage when it is destroyed by keeping or discarding your reference to the wx.WindowIDRef object.

 

Given that NewId still works and does not issue a deprecation error, I am safe to keep using it or will it stop working in the future with the same ruthlessness that it joined the culled group of commands? If so, which of the 2 new options should I use as a drop in replacement?

Since it's marked as deprecated in wxWidgets then it will eventually be removed. Following policy it shouldn't happen before 4.2 (wxWidgets 3.2) though.

 

The issue that I have with NewRefId is that it is negative, so when one creates a Bind command that utilises by "id" and "id2"

such as

self.Bind(wx.EVT_MENU, self.OnAutoTimeStamp, id=TIMESTAMP_OFF,id2=TIMESTAMP_COMMENT)

previously, using NewId one got positive numbers that worked smoothly with this feature.

Now the Id's have to be assigned backwards because of the negative number issue, it is counter intuitve.

The smaller number is still the first ID returned, so you should not need to change the order, being negative doesn't change the incrementation order.

>>> id1, id2 = wx.NewId(), wx.NewId()

>>> id1 < id2

True

>>> id1, id2 = wx.NewIdRef(), wx.NewIdRef()

>>> id1 < id2

True

> P.S.

> I forgot to mention, where does wx.RegisterId() fit with regard to wx.NewIdRef() and wx.Window.NewControlId()

It doesn't. wx.RegisterId simply sets the counter used by wx.NewId to the given value+1. Since the wxIdManager and wxWindowIDRef manage to avoid conflicts on their own there isn't any need for that.

--

Robin

[Robin Dunn]

On Thursday, June 28, 2018 at 10:22:15 AM UTC-7, Robin Dunn wrote:

On Thursday, June 28, 2018 at 7:34:26 AM UTC-7, rolfofsaxony wrote:

  

Loading up 4.0.3 I now have

wx.NewId() - no deprecated warning and still working happily

I think that whether you see the warning by default can depend on Python version, platform, environment and what mode Python is running in. Resetting the warnings filter will make them visible again. For example:

>>> import wx

>>> wx.NewId()

100

>>> import warnings

>>> warnings.simplefilter('default')

>>> wx.NewId()

__main__:1: DeprecationWarning: NewId() is deprecated

101

>>>

I just realized why it isn't showing up by default. It's using the stock DeprecationWarning, not our wxPyDeprecationWarning, and the former is turned off by default unless you set flags on the command line or environment or explicitly turn it back on. I should check if there is a way to have sip use our deprecation class for those items marked as deprecated in that way...

 

--

Robin

 

[rolfofsaxony]

Thank you Robin for taking the time to come back to me.

You are correct about the Bind id= id2= issue.

I appear to have been confused by an error message that kept popping up.

An error that still seems a tad baffling.

Previously I have declared some fixed Id's as:

TIMESTAMP_OFF = wx.NewId()

TIMESTAMP_STD = wx.NewId()

TIMESTAMP_BOOKMARK = wx.NewId()

TIMESTAMP_COMMENT = wx.NewId()

With the demise of NewId I changed this is to:

TIMESTAMP_OFF = wx.NewIdRef().GetId()

TIMESTAMP_STD = wx.NewIdRef().GetId()

TIMESTAMP_COMMENT = wx.NewIdRef().GetId()

TIMESTAMP_BOOKMARK = wx.NewIdRef().GetId()

and get this error:

    self.autom.AppendRadioItem(TIMESTAMP_OFF, 'Turn Off Automatic Timestamps')

wx._core.wxAssertionError: C++ assertion "gs_autoIdsRefCount[winid] != ID_FREE" failed at /home/vagrant/wxPython-4.0.3/ext/wxWidgets/src/common/windowid.cpp(110) in IncIdRefCount(): id should first be reserved

If however I use:

TIMESTAMP_OFF = wx.Window.NewControlId()

TIMESTAMP_STD = wx.Window.NewControlId()

TIMESTAMP_COMMENT = wx.Window.NewControlId()

TIMESTAMP_BOOKMARK = wx.Window.NewControlId()

The code works as it did before.

So whilst I have a resolution, I am still a tad confused.

I'm happy to accept that this may be more my own density than an issue with wxPython but I'm sure that I won't be the only one to not immediately get to grips with it.

Regards

Rolf

p.s. warnings.simplefilter('default') was an eye opener!

[rolfofsaxony]

Ok got it!

use:

TIMESTAMP_OFF = wx.NewIdRef()

TIMESTAMP_STD = wx.NewIdRef()

TIMESTAMP_COMMENT = wx.NewIdRef()

TIMESTAMP_BOOKMARK = wx.NewIdRef()

I assume wxPython does the transformation behind the scenes

[Robin Dunn]

On Friday, June 29, 2018 at 2:48:43 AM UTC-7, rolfofsaxony wrote:

Ok got it!

use:

TIMESTAMP_OFF = wx.NewIdRef()

TIMESTAMP_STD = wx.NewIdRef()

TIMESTAMP_COMMENT = wx.NewIdRef()

TIMESTAMP_BOOKMARK = wx.NewIdRef()

I assume wxPython does the transformation behind the scenes

Correct. There is a __int__ method to convert to an integer as needed.

--

Robin