Opened 9 years ago

Last modified 8 years ago

#13888 accepted defect

SetToolBar doesn't work if ToolBar already has tools (osx cocoa)

Reported by: mmacleod Owned by: csomor
Priority: normal Milestone:
Component: wxOSX Version: 2.9.2
Keywords: osx cocoa wxtoolbar toolbar blank crash Cc: scottwx@…, vaclavslavik
Blocked By: Blocking:
Patch: no

Description

On MSW (and Carbon) it is possible to create a wxToolBar, set up all its children and finally call SetToolBar to have it displayed.
On osx Cocoa this instead leads to a completely blank toolbar showing, the toolbar only displays correctly if the sequence is changed so that SetToolBar is called first and only then are tools added.

Furthermore if one calls SetToolBar on a Toolbar that already has tools and then after doing that attempts to add any further tools this results in a crash. It also appears that a ToolBar in this state can lead to intermittent crashes on program exit as well.

Ideally this should be fixed so that SetToolBar can be used in the same manner as it is on MSW. However it's quite possible that this cannot be done under Cocoa, for whatever reason.
If it cannot be done this way under Cocoa then at the very least the documentation should warn about this and ideally a debug assertion should be thrown when calling SetToolBar, doing this could save a lot of frustrated developers some time.

Attachments (2)

SetToolBarProblemSample.diff download (923 bytes) - added by mmacleod 9 years ago.
Patch to Toolbar sample that demonstrates incorrect behaviour
xh_toolb.diff download (564 bytes) - added by scottb 9 years ago.
wxXmlResource::LoadToolBar patch

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

could you please attach a diff to a sample that allows me to reproduce the erroneous behavior easily ? Thanks!

comment:2 Changed 9 years ago by csomor

  • Status changed from accepted to infoneeded

Changed 9 years ago by mmacleod

Patch to Toolbar sample that demonstrates incorrect behaviour

comment:3 Changed 9 years ago by mmacleod

  • Status changed from infoneeded to accepted

Patch to reproduce the behaviour is added as attachment

comment:4 Changed 9 years ago by scottb

  • Cc scottwx@… added
  • Patch set

This issue sounds like what I ran into and worked around already with cocoa.

I'm using wxGlade and a resource.cpp file for all my dialogs and the toolbar.
When I first built with cocoa, the toolbar was blank. I carefully traced down
and compared the sample's sequence of building the toolbar and items and
compared it with the xrc code.

What I finally discovered was that toolbar->Realize ( ) will fail if the parent
is not set first.

Attached is my patch which moves the Realize call. (I've not verified it on
other platforms but since it matches the sample sequence it should be fine.)

The weakness of this patch is that if dontattachtoframe is set it will still
fail.

The best fix would be, if possible, to make the realize call work without
a parent. It may be an easy fix, but it was just never tried. Then we would
ignore my patch.

If it can't be fixed because of cocoa, then we know what to document.

I just re-read the description of the problem on this bug and am guessing
that the real problem is that Realize is being called as each child is
being added and it's failing because there is no parent yet.

Changed 9 years ago by scottb

wxXmlResource::LoadToolBar patch

comment:5 Changed 9 years ago by scottb

  • Patch unset

comment:6 Changed 9 years ago by vadz

  • Milestone set to 3.0

I think it should be possible to allow calling Realize() without parent. All we need to do is to actually do nothing at this time and do whatever it normally does when the parent is finally set.

Stefan, would there any problem with this?

If we don't have time to do this, at least the patch from comment:4 should be applied. It's not perfect -- as explained in the comment itself -- but better than nothing.

comment:7 Changed 9 years ago by vaclavslavik

  • Cc vaclavslavik added

comment:8 Changed 9 years ago by VS

(In [72164]) Call Realize() later in XRC toolbar handler (patch #13888).

This is a workaround for a deeper compatibility problem in Cocoa
implementation (see the bug for detailed discussion), but for now, this
simple workaround is much better than not doing nothing.

See #13888.

comment:9 Changed 8 years ago by vadz

  • Milestone 3.0 deleted

This is not 3.0-critical any more after applying the XRC patch. Still would be nice to fix it, of course...

Note: See TracTickets for help on using tickets.