Code::Blocks on MacOSX

[byo]

I was maybe a little too quick to announce total MacOSX success, one remaining issue is wxSmith.

wxSmith has issues in other platforms too, so don't worry. Eventually, byo will fix it .

Linux may be easy thing but is there any way to emulate Mac behaviour ? I tried to fix some bugs but it still takes 2GB of memory:/

[afb]

Linux may be easy thing but is there any way to emulate Mac behaviour ?

I'm afraid you'll have to use a Mac.

[Game_Ender]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

[takeshimiya]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

Usually is just a bug that in some platform (Windows) goes unnoticed or doesn't happens while it appears on others (Linux/Mac).
AFAIK wxSmith doesn't uses non-cross platform code.

Has anyone tried valgrind (It even exists there?) on Mac? or any equivalent?
And debugging it?

Anyways the issues raised by afb haves more priority than wxSmith currently.

[Game_Ender]

Has anybody run valgrind over CB on Linux recently?  Valgrind is being ported to mac, we just half to wait.

[byo]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

It's system used in editor to draw over widgets (f.ex. adding these black boxes around item allowing to resize / move them). I've tried to handle repaint events for all widgets in edited resource but it wasn't enough (and to be more clear: wxWidgets is really buggy in handling of paint/mouse events for standard widgets). So currently I do some trick - I paint all items and after it's done I fetch picture directly from screen, hide items and use that fetched picture as background for editor. It's hard to do make some universal technique but I believe it's donnable.

Other things are incompatibilities in raising events. I don't remember exactly but after setting some text on item manually it raises text-changed event on some platforms and doesn't on other. So it may work on windows but may fail on linux etc.

Anyways the issues raised by afb haves more priority than wxSmith currently.

True, wxSmith is not required to make C::B running.
But it doesn't mean I will stop porting wxSmith .

[Game_Ender]

This is quite a hack you have there.  Sorry to hear the wxWidgets is in a such a state that it requires you to do that.  I wonder how DialogBlocks does it?  I always assumed there was just a special version of each standard widget that drew a rectangle around its border with during the proper paint event.

[tiwag]

.... So currently I do some trick - I paint all items and after it's done I fetch picture directly from screen, hide items and use that fetched picture as background for editor...

that's maybe the reason why i do most of the time only see a black box instead of the created dialogue  :?