rev 2173

[sethjackson]

I have Version 1.0 revision 2173 (gcc 3.4.4 Windows/unicode, build: Mar 10 2006 21:28:07) on Windows XP.
I have found a really nasty problem. 

BTW The March 9 nightly doesn't have this problem. The March 11, and March 10 nightlies do.

1. Remove your default.conf from %APPDATA%\codeblocks. Make sure you do not delete it. Put it somewhere safe.

2. Open CodeBlocks.cbp from SVN sources.

3. C::B never opens. (Windows says it can't find CodeBlocks.cbp (DDE bug :? ) )

4. Open C::B just by running codeblocks.exe. C::B never opens.

5. Put default.conf back. C::B works again.  :shock:

I have no idea what causes this. Most people probably won't delete their default.conf, but still the above shouldn't happen......

[thomas]

This is due to the wxSTAY_ON_TOP flag in the new splash screen class.

I told you, I told you, I told you... we already had this bug once.

When the "select default compiler" dialog tries to show up, the wxSTAY_ON_TOP flag prevents it from doing so ---> app freezes.

It's fixed in SVN.

[sethjackson]

This is due to the wxSTAY_ON_TOP flag in the new splash screen class.

I told you, I told you, I told you... we already had this bug once.

When the "select default compiler" dialog tries to show up, the wxSTAY_ON_TOP flag prevents it from doing so ---> app freezes.

It's fixed in SVN.

EDIT:

See next post.

[sethjackson]

Umm no go. C::B uses 99% CPU now.

[thomas]

OK, so there are two issues. The other one was true nevertheless

[thomas]

That is related to the new splash screen for certain, too.
Try running codeblocks -ns... works fine.

[thomas]

Narrowed it down to MainFrame::ScanForPlugins().

[thomas]

It works without the compiler plugin (which displays the modal "select default" dialog). My guess is that it is some issue between that dialog and the new splash screen (having fun with activate events?).

[Ceniza]

Thomas: I thought you were going to use the style parameter in the constructor... :?

BTW, could you make this little change which is used in wxSplashScreen?

Replace, in cbSplashScreen's constructor (CPP file):

Code (cpp) Select Expand

Update();

With:

Code (cpp) Select Expand

#if defined(__WXMSW__) || defined(__WXMAC__)
  Update();
#else
  wxYieldIfNeeded();
#endif

Thanks (if you do)

[thomas]

BTW, could you make this little change

Did that (does of course not solve the problem).

Any ideas on what to do on that behalf? I believe it is a problem with activating/deactivating frames. I had a similar effect once when redesigning the file association stuff (using a dialog instead of an alert), and finally solved it by moving the dialog to a later stage when the splash screen was already destroyed and the main frame was active. With plugin initialisation, that may prove awkward.

Might experiment if the compiler plugin could hide it in case it needs to, but that's actually not such a pleasant solution either. A plugin should not fiddle with the application in such a way.

[Ceniza]

Few differences with wxWidget's implementation:

wxSS can receive a parent.
wxSS creates a special widget to draw the bitmap and adds it to the frame (I tried this already but the results in Linux aren't that good).
wxSS stops the timer in its destructor.
wxSS has an OnCloseWindow function that stops the timer and destroys the frame (thru EVT_CLOSE).
wxSS adds EVT_CHAR and EVT_MOUSE_EVENTS to its child window, which will close the window.

I wonder if adding some of those would be of any help.

BTW, the splash sample does it this way:

The main frame is created first (just created). Now the splash screen is created with the frame as parent. Follows a call to wxYield() and then frame->Show(true).

I'll try to add some of those changes to my working copy and commit them to SVN (http://svn.cenizasoft.cjb.net/ -> BattleCS -> Server).

[Ceniza]

It's now committed.

The only thing I didn't implement was the use of a child widget to draw.