Best practice for replacing deprecated NewId

We have a handful of pure-Python classes, not derived from any wxWidgets class, that emulate the API of things like Menu or MenuItem (as a simple example). When constructing these objects, they are currently assigned an id using wx.NewId(), which is then used to bind them to various events. We can’t use wx.ID_ANY (-1) for these, since that’s simply a flag to wxWidgets to generate a real id. Is there some sanctioned means for generating a unique id that is not deprecated?

How will all the 100+ calls to NewId in wxPython itself, like the one below, be fixed?

site-packages/wx/py/frame.py:28:ID_HELP = wx.NewId()

Never mind. :slight_smile:

I get the digest for this group, and of course the answer was already published when I hit send… Just use wx.Window.NewControlId instead.

···

On Mon, Jun 18, 2018 at 11:17 AM Eric Fahlgren ericfahlgren@gmail.com wrote:

We have a handful of pure-Python classes, not derived from any wxWidgets class, that emulate the API of things like Menu or MenuItem (as a simple example). When constructing these objects, they are currently assigned an id using wx.NewId(), which is then used to bind them to various events. We can’t use wx.ID_ANY (-1) for these, since that’s simply a flag to wxWidgets to generate a real id. Is there some sanctioned means for generating a unique id that is not deprecated?

How will all the 100+ calls to NewId in wxPython itself, like the one below, be fixed?

site-packages/wx/py/frame.py:28:ID_HELP = wx.NewId()

Hi Eric,

Is wx.NewId() deprecated?? I have a lot of new code (and I saw it in the phoenix demo too) with these for example:

ID_MnuSalir = wx.NewId()

···

Saludos / Best regards

Mario Lacunza
Email:: mlacunza@gmail.com
Personal Website:: http://www.lacunza.biz/
Hosting:: http://mlv-host.com/
Skype: mlacunzav

Lima - Peru

At the risk of being labeled a curmudgeon, there is no magic to
NewId. You can do exactly the same thing in pure Python by using:

    import itertools

    NewIdGen = itertools.count()

    def NewId():

        return NewIdGen.next()
···

timr@probo.com

At the risk of being labeled a curmudgeon, there is no magic to
NewId. You can do exactly the same thing in pure Python by own
code using

    import itertools

    NewIdGen = itertools.count()

    def NewId():

        return NewIdGen.next()
···

timr@probo.com

With the advent of wx.NewIdRef() in Phoenix, personally I trawled through my code and adjusted it accordingly.
However, I discovered of course, that I’d shot myself in the foot if I was testing on a version of wxpython prior to 4.0.2

To allow for this, I simply put the following at the top of my code to allow for it.

def ref_id():

return wx.NewId()

try: #Work around for wxpython prior to 4.0.2 where wx.NewIdRef first appeared

TestId = wx.NewIdRef()

except:

wx.NewIdRef = ref_id

i.e. no NewIdRef use NewId instead

···

On Monday, June 18, 2018 at 8:17:23 PM UTC+2, efahl wrote:

We have a handful of pure-Python classes, not derived from any wxWidgets class, that emulate the API of things like Menu or MenuItem (as a simple example). When constructing these objects, they are currently assigned an id using wx.NewId(), which is then used to bind them to various events. We can’t use wx.ID_ANY (-1) for these, since that’s simply a flag to wxWidgets to generate a real id. Is there some sanctioned means for generating a unique id that is not deprecated?

How will all the 100+ calls to NewId in wxPython itself, like the one below, be fixed?

site-packages/wx/py/frame.py:28:ID_HELP = wx.NewId()