Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?

[Game_Ender]

And since the default Mac OS X file manager or the default file dialogs won't help them find the files, many users won't do so.

Just a helpful tip: You can get directories like /usr/local by just using Command+Shift+G in finder.  A box pops up and you can type in any path you want, if I remember correctly it even has tab completion.

[Pecan]

I'm really surprised that a Mac programmer/developer is not expected to know how to use terminal and the minimum *nix commands.

I don't know how you can ask this, since there are users in this forum that doesn't know even what a project is, or how to debug let alone where the problem was.
This is way off-topic too

It is not off-topic.

My point is: you are going to a lot of trouble to code and implement changes to CodeBlocks for which a programmer/developer should reasonable be expected to know.

N00bies are different. They're expected to read books and ask questions in order to become a knowledgeable programmer/developer who, on learning how to use an OS, can then find ./codeblocks and become proficient in CB.

Is this an IDE for kindergarten or developers?

[thomas]

Why are you using wxStandardPathsBase? The "standard" way should be like this:

Code

wxStandardPaths::Get().GetUserDataDir()

Anyway, I don't know if this fixes your crash, but I never had any problems with this line of code (not on Windows and not on Linux).

I sure was doing what you call the standard way

The problem was that I had put all the path names along with initialising code into a static object, so initialisation is done implicitely, and we can avoid calling if(someVariable.IsEmpty()) a hundred times.

Unluckily, wxStandardPaths does not like being called from global constructors... although the documentation speaks of "initialised to reasonable values", the meaning of "reasonable" is apparently NULL.
I've reduced all the checks to testing one boolean now, and initialisation is done the first time any directory function is used... that works, but I am not 100% happy with it.

[Der Meister]

Ah, OK, that explains matters...
I guess the problem with your first approach is that you can't say anything about the order in which static and global objects were intialized - maybe your static variable was initialized before the wxStandardPaths structures?

[thomas]

Yeah well.... a common problem

I had expected, though, that since you instantiate the wxStandardPaths singleton before using it, its data would be valid. But unluckily, that doesn't hold. It still only works after wxApp::OnInit().

The way it is now is probably as good as it can get, oh well... I'll keep it around for a day or two to see if anything works differently from what you would expect, and will commit then.

[afb]

They are talking about releasing wxWidgets 2.7.2 on Friday, tomorrow, at 0900 GMT; I think this is 0400 EST. Edit: Person asked them to hold off till Monday so he/she could finish some task.

Note: I have given up on 2.7.1 because the docs have not been updated enough on wxDialog for me to figure out the changes in the wx27 code and how to patch C::B.
Edit: Found suggestion that pointed me in the correct direction to get 2.7.1 to compile & link.

Note: I am working on getting the patches ready for C::B for wxWidgets 2.7.0; I still testing changes for problems with 2.63p2, having issues with the SVN changing for the files I am patching. I have decided to break my patch into 4 (plus 1 for 2.7.1) small patches. ( 5 total files involved in all patches for 2.7.0 and 2 files for 2.7.1 for now.)

Eventually launched with wxWidgets 2.7.2 on wxMac, after patching a couple of files. The wxAUI palettes are all blank, and some of the dialogs crash, but it did succceed to compile a link. We should get your wx 2.7 patches integrated with Code::Blocks as soon as possible to get ready for wxWidgets 2.8.0, I think.

Will upload the patches to BerliOS.

[stahta01]

Eventually launched with wxWidgets 2.7.2 on wxMac, after patching a couple of files. The wxAUI palettes are all blank, and some of the dialogs crash, but it did succceed to compile a link. We should get your wx 2.7 patches integrated with Code::Blocks as soon as possible to get ready for wxWidgets 2.8.0, I think.

Will upload the patches to BerliOS.

Many of the icons or bitmaps are missing under 2.72/CVS under windows also.

Tim S

[stahta01]

Release of wxWidgets 2.7.2 has been started.

[afb]

The first couple of tarballs were broken (had to be respun), and it looks like it still has issues with XRC when I tried the CVS earlier. All the images in the toolbars were missing, and the xrcdemo sample seemed to be crashing as well ? (posted some wxAUI and other patches to BerliOS)

So I guess that wx 2.7 will continue to be bleeding edge long after wx 2.8.0 arrives... Then again that's just in a week or so.  :shock:

[sethjackson]

wxAUI is now part of wx so we shouldn't need it (in the C::B sources) anymore if (and presumeably when) C::B switches to either 2.7 or 2.8.

EDIT:

Shoulda read more carefully.

[David Perfors]

Beside that, we have to wait for the thirdparty libs (wxScintilla amd wxPropGrid) to support the new version. That is nicer than patching those libs ourself.

[stahta01]

The only thing I can find that requires WXWIN_COMPATIBILITY_2_4 to be 1 seems to be the use of wxHIDE_READONLY. So, when we are ready to move to support for wxWidgets 2.8 we need to decide how to handle wxHIDE_READONLY. I see two ways remove them or place then in #if wxCHECK_VERSION blocks.

Note: A third way I used as testing work around was to -DwxHIDE_READONLY=0 with WXWIN_COMPATIBILITY_2_4 set to 0 in setup.h.

I also looked up the deprecated methods messages on compiling C::B (did not look at contrib messages yet.)

2.4 deprecated methods with Good Methods under 2.6 per chm and headers
  ::wxStartTimer                       // This is deprecated use wxStopWatch::Start instead
  ::wxGetElapsedTime                // This is deprecated use wxStopWatch::Time instead
  wxDC::BeginDrawing                // This is deprecated and does nothing. Don't use.
  wxDC::EndDrawing                  // This is deprecated and does nothing. Don't use.
  ::wxGetWorkingDirectory          // See ::wxGetCwd as a replacement

2.6 deprecated methods with New Methods under 2.7 per chm and headers
  wxWindow::SetBestFittingSize    // See SetInitialSize(size) as a replacement
  wxWindow::GetBestFittingSize    // See GetEffectiveMinSize() as a replacement
  wxRect::Inside                        // See wxRect::Contains as a replacement
  wxAuiManager::SetFrame          // See wxAuiManager::SetManagedWindow as a replacement

deprecated methods with questions about how to fix or if they need fixing
  wxPathList::Member                 // May or may NOT be deprecated; conflicting code and docs
  __comp_ctor wxFontDialog::wxFontDialog see include/wx/msw/fontdlg.h:42


Tim S

[afb]

Note: A third way I used as testing work around was to -DwxHIDE_READONLY=0 with WXWIN_COMPATIBILITY_2_4 set to 0 in setup.h.

I did this too, but stuck it in the header.

Code

#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif

[afb]

wxAUI is now part of wx so we shouldn't need it (in the C::B sources) anymore if (and presumeably when) C::B switches to either 2.7 or 2.8.

Please see the AUI patch, there is no currently need to choose -
you can have same CB code link with both wx 2.6 and wx 2.8 ?

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1630&group_id=5358

[rjmyst3]

Beside that, we have to wait for the thirdparty libs (wxScintilla amd wxPropGrid) to support the new version. That is nicer than patching those libs ourself.

wxPropGrid and wxScintilla already support wxWidgets2.7 - we use them in wxFormBuilder, which is built with wxWidgets2.7.