The 12 January 2019 build (11552) is out.

[stahta01]

Using Monolithic build of wxWidgets-3.1.2.

Started having issues with SVN 11552 source. Used mingw-w64-gcc-8.1.0 as the compiler since it started being used to create NBs.

Regards

You did try rebuilding the two projects with the virtual target "All" selected?

Tim S.

[Frank_CB]

You did try rebuilding the two projects with the virtual target "All" selected?

I never noticed when it was orginaly done, so I just redid it with "All" definitely selected. Exporter failed again.  Removed Expoorter and Spellchecker files from workspace and rebuilt.  Workspace completed successfully.  Re-added files for Exporter and Spellchecker recursively.

Exporter failed again because it couldn't find wxScintilla.h.  Spellchecker failed again because it couldn't find annoyingdialog.h.  I coidn't find either header file in wxWidgets-3.1.2\includw. What does that imply?

Regards.

[oBFusCATed]

Exporter failed again because it couldn't find wxSinctilla.h.  Spellchecker failed again because it couldn't find annoyingdialog.h.  I coidn't find either header file in wxWidgets-3.1.2\includw. What does that imply?

These are files from the cb's sources and not from wxwidgets. Something is broken on your side, I guess, but I'm not using windows regularly, so I don't know.

[Frank_CB]

These are files from the cb's sources and not from wxwidgets. Something is broken on your side, I guess, but I'm not using windows regularly, so I don't know.

Thanks for the information.

I found those headers in SVN 11554's source.  Will try to fix the two plugins on my platform.

Regards. 

[Frank_CB]

...Will try to fix the two plugins on my platform.

My bad.

Had used wrong URL to obtain SVN 11554 source.  Have made correction.

Exporter and SpellChecker now building correctly within workspace. Building rest of workspace currently.

Thanks for the suggestions and remarks!

Regards.

[delphi13]

Unless I am missing something really obvious, it appears the pre-build steps are not being called when rebuilding a project using the Code::Blocks command line.  Inside the environment everything is working fine, but when called with --rebuild from the command line it exits almost immediately with "Nothing to be done (all items are up-to-date)."  I couldn't see any options on the Wiki for command line use referring to the pre or post steps.

I upgraded to this nightly from an older install (17.12) hoping it might be fixed, but there was no change.

I've successfully automated other projects to build using the command line, but this one needs a pre-build step to run qmake.

Any suggestions?

[BlueHazzard]

Can you provide full steps to reproduce, with minimal example project?

[delphi13]

It appears my "Unless I am missing something really obvious" statement came true. While building the minimal example I had the same problem occur. However when double checking things before submitting I noticed the case was wrong on the build target name ("Release" vs. "release"). Going back to my original project I had done the same thing there.

If you're open to process improvements, perhaps an error could be added to Code::Blocks if the command line --target doesn't match any of the build target names in the project. Currently it displays "Nothing to be done (all items are up-to-date)." which is not the most helpful thing when trying to debug human errors.

It's the simple things that often take the longest to find. Sorry for the false alarm.

[Manolo]

Since several nighties, C::B flickes on the task bar when it starts. See attached gif (the smallest I could create).

Windows 10 1803 (17134.523)

[BlueHazzard]

If you're open to process improvements, perhaps an error could be added to Code::Blocks if the command line --target doesn't match any of the build target names in the project. Currently it displays "Nothing to be done (all items are up-to-date)." which is not the most helpful thing when trying to debug human errors.

a ticket only for you: https://sourceforge.net/p/codeblocks/tickets/796/

[riban]

Since several nighties, C::B flickes on the task bar when it starts. See attached gif (the smallest I could create).

Windows 10 1803 (17134.523)

I experience this too. I thought it might be something else in Windows but I guess it is only CodeBlocks doing it. I see this with Windows 7 Professional 64-bit.

[Miguel Gimenez]

The flickering has been always there (every time a plugin loads a C::B icon appears and then disappears).

Now it is more visible because the old splash screen created a fixed icon that covered the plugin icons almost completely, but the new splash screen (using wxSplashCreen from wxWidgets) does not create such task bar icon.

[oBFusCATed]

Can someone try to find why this problem happens?

[BlueHazzard]

every time a plugin loads a C::B icon appears and then disappears

Plugins or wxAUI windows? I was thinking this comes from top level windows created...
I do not think that there is an easy fix...

[Miguel Gimenez]

Plugins or wxAUI windows?

Will check.

The problem with wxSplashScreen is that it uses wxFRAME_TOOL_WINDOW and wxFRAME_NO_TASKBAR; both imply that no taskbar icon will be shown.

There are three possible solutions:
  1.- restore previous behaviour of the splash screen (icon in taskbar with flashing icons behind it)
  2.- no icon with splash screen and try to remove flashing icons for plugins/AUI windows
  3.- Icon with splash screen, try to remove flashing icons.

Option 1 is easy. Option 2 means no icon will be shown until the main window is opened, and may be less easy. 3 may be easy or not.

Which is the preferred way?