Best practice for replacing deprecated NewId

[Eric Fahlgren]

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()

[Eric Fahlgren]

Never mind. :)

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.

[Mario Lacunza]

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:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
Hosting:: http://mlv-host.com/
Skype: mlacunzav

Lima - Peru

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Roberts]

On 06/18/2018 11:17 AM, Eric Fahlgren 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?

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()

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Tim Roberts]

On 06/18/2018 11:17 AM, Eric Fahlgren 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?

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

[Anders Munch]

Tim Roberts:
> 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:

No that doesn't work, because it doesn't coordinate with everyone else's ID's. It's a collision waiting to happen.

regards, Anders

[john fabiani`]

+1

Johnf

[Robin Dunn]

The only thing that wxNewId does better is to avoid returning IDs in the range of wxID_LOWEST..wxID_HIGHEST. Other than the range of stock IDs wxNewId is just as susceptible to collisions.  Here is the implementation:

// Id generation

static int wxCurrentId = 100;

int wxNewId()

{

    // skip the part of IDs space that contains hard-coded values:

    if (wxCurrentId == wxID_LOWEST)

        wxCurrentId = wxID_HIGHEST + 1;

    return wxCurrentId++;

}

If you can't use wx.ID_ANY (or -1) then use wx.Window.NewControlId if you care about avoiding collisions.

--

Robin

 

[Florian Höch]

Hi Robin, everyone,

Am 19.06.2018 um 18:30 schrieb Robin Dunn:
> If you can't use wx.ID_ANY (or -1) then use wx.Window.NewControlId if
> you care about avoiding collisions.

just to make sure, is wx.Window.NewControlId also the proper replacement
when the ID is not used for a control (i.e. custom events, timers etc)?

Thanks,

Florian.

[Robin Dunn]

Yes, it will work although I wonder if you are confusing event type with control ID for custom events? If the event's source is a widget or other UI item then you should be setting the ID in the event to be the ID of the source object. For example, the ID in the event object for EVT_BUTTON events is the ID of the button that was pressed, but the event type for all EVT_BUTTON events is wx.EVT_BUTTON.evtType. 

On the other hand, if the custom event is not used as coming from a source with an ID then I probably wouldn't even bother setting the ID in the event object. It would only really be needed if you need to Bind() it to different handlers depending on the source of the event. (On the other other hand, IMO there are better ways to pass messages around for non-UI elements than using wx events...)

While on this subject I'd like to point out a few things that have been done to minimize the need to have preallocated IDs in wxPython, over what wxWidgets already does. In fact, back in the early days of this project there were a number of advocates of eliminating or at least hiding the ID parameters throughout all of the wxPython API, because they aren't really necessary in most cases, and the remaining ones could likely be worked around easily. When you boil it all down to the nitty-gritty, the primary purpose of IDs is for identifying the source of events when searching for matching handlers, but there are many cases where it simply doesn't matter.

 

1. Many consider it more pythonic to Bind() an event handler directly to the widget the produces the event, such as binding EVT_BUTTON to the button object itself. In this case, the button's ID does not matter since there can only be one source of button events seen at that point in the hierarchy. So the following works and no specific IDs need to be dealt with at all:

obj = SomeWidget(self, wx.ID_ANY, ...)

obj.Bind(wx.EVT_SOMETHING, self.myHandler)

2. Building on that concept a little more, if there is only ever one source of a particular kind event in some containment hierarchy (up to the point of the object the handler is bound to) then again, the ID of that source doesn't matter, at least for the purpose of binding and finding event handlers for that event type. And it definitely doesn't matter if the same ID is used in another containment hierarchy. Again, the specific ID of the widget is not needed.

obj = SomeWidget(self, wx.ID_ANY, ...)

self.Bind(wx.EVT_SOMETHING, self.myHandler)

 

3. When there can be multiple sources of the same event type within a containment hierarchy which need to be routed to different handlers then the third parameter of Bind() (named 'source') can be used to accomplish that, and still there is no need to use and know specific ID values.

objA = SomeWidget(self, wx.ID_ANY, ...)

objB = SomeWidget(self, wx.ID_ANY, ...)

self.Bind(wx.EVT_SOMETHING, self.myAHandler, objA)

self.Bind(wx.EVT_SOMETHING, self.myBHandler, objB)

4. Thanks to the magic of Python the source parameter of the Bind() method can take any kind of object which has a GetId() method. That includes all windows/widgets, menu and toolbar items (which are returned by the methods which add the items to the menu or toolbar), timers, and so forth. If there is anything that can be the source of an event that does not have a GetId() method then I would consider that to be a bug and it should be reported. Since it's Python then it can also be non-UI objects that have a GetId() method, if that makes sense for the design of your application.

item = menu.Append(wx.ID_ANY, "&Foo", "Do some foo stuff")

self.Bind(wx.EVT_MENU, self.onDoFoo, item)

5. If you ever do need to know the ID of an item then you can just call it's GetId().

item = menu.Append(wx.ID_ANY, "&Foo", "Do some foo stuff")

toolbar.AddTool(item.GetId(), "Foo", fooBmp, "Do Some Foo stuff") 

self.Bind(wx.EVT_MENU, self.onDoFoo, item)

6. One other common place where I've seen people wanting to use specific IDs is in event handlers to differentiate behavior based on the source of the event. For example:

 

def OnHandleButtons(self, evt):

    if evt.GetId() == ID_A:

        self.doSomething()

    elif evt.GetId() == ID_B:

        self.doSomethingElse()

    ...

However it's just as easy to compare the event's source object itself, and is also a stronger way to dispatch based on source in the rare case where there is a duplicate ID conflict.

def OnHandleButtons(self, evt):

    if evt.GetEventObject() is self.objA:

        self.doSomething()

    elif evt.GetEventObject() is self.objB:

        self.doSomethingElse()

    ...

OTOH, it is also simple to bind a separate handler for each of the cases above and that would also be a better OOP design.

This obviously doesn't cover all use cases now and forever, but it should show that the need to use and reuse preset ID values is lower than some people may think, and that the desire is that they should not be needed at all.

HTH,

Robin

[john fabiani`]

This a good tutorial - maybe in can be on the website?

Johnf

[Robin Dunn]

On Wednesday, June 20, 2018 at 4:47:10 PM UTC-7, johnf wrote:

This a good tutorial - maybe in can be on the website?

Indeed. http://localhost:8000/blog/avoiding-window-ids/index.html

--

Robin

 

[Robin Dunn]

Oops, wrong link. This is it: https://wxpython.org/blog/avoiding-window-ids/index.html

--

Robin

[Andrea Gavana]

Hi Robin,

One possibility that not (directly) mentioned is the handling of wx.EVT_UPDATE_UI events for menus and toolbar buttons. 

I sometimes like to have the most important functionalities of an application available from a menu item and from a toolbar button (as a shortcut and faster way to access it). Since the most common (for me, at least) way to enable/disable a menu/toolbar button is through wx.EVT_UPDATE_UI events, it may get a bit cumbersome without explicit IDs. It can be done without, of course, but I find it very convenient to use wx.NewId() for these circumstances.

Andrea.

--

Robin

[Edward Sitarski]

Is there a solution for SetAccelleratorTable where the keyboard accellerators do not correspond to a current UI component?

For example, my current code looks like this:

idRecordAcceleratorId, idCommitAccelleratorId = wx.NewId(), wx.NewId()

self.Bind(wx.EVT_MENU, self.doRecordTime, id=idRecordAcceleratorId)

self.Bind(wx.EVT_MENU, self.doCommit, id=idCommitAccelleratorId)

accel_tbl = wx.AcceleratorTable([

(wx.ACCEL_NORMAL,  ord('T'), idRecordAcceleratorId),

(wx.ACCEL_NORMAL,  ord('S'), idCommitAccelleratorId),

])

self.SetAcceleratorTable(accel_tbl)

Thanks.

[rolfofsaxony]

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