Author Topic: The 12 January 2019 build (11552) is out.  (Read 13977 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6665
    • My Best Post
Re: The 12 January 2019 build (11552) is out.
« Reply #15 on: January 18, 2019, 01:22:08 pm »
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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: The 12 January 2019 build (11552) is out.
« Reply #16 on: January 18, 2019, 06:32:21 pm »
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.
« Last Edit: January 18, 2019, 06:36:48 pm by Frank_CB »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12069
    • Travis build status
Re: The 12 January 2019 build (11552) is out.
« Reply #17 on: January 18, 2019, 06:36:03 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: The 12 January 2019 build (11552) is out.
« Reply #18 on: January 18, 2019, 07:50:19 pm »
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. 

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: The 12 January 2019 build (11552) is out.
« Reply #19 on: January 19, 2019, 05:58:27 pm »
...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.

Offline delphi13

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 12 January 2019 build (11552) is out.
« Reply #20 on: February 05, 2019, 09:38:45 pm »
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?

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2545
Re: The 12 January 2019 build (11552) is out.
« Reply #21 on: February 06, 2019, 12:15:30 am »
Can you provide full steps to reproduce, with minimal example project?

Offline delphi13

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 12 January 2019 build (11552) is out.
« Reply #22 on: February 06, 2019, 06:36:36 pm »
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.

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 12 January 2019 build (11552) is out.
« Reply #23 on: February 06, 2019, 09:17:28 pm »
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)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2545
Re: The 12 January 2019 build (11552) is out.
« Reply #24 on: February 07, 2019, 02:03:11 am »
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/ ;)

Offline riban

  • Multiple posting newcomer
  • *
  • Posts: 26
Re: The 12 January 2019 build (11552) is out.
« Reply #25 on: February 21, 2019, 02:45:10 pm »
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.

Offline Miguel Gimenez

  • Regular
  • ***
  • Posts: 369
Re: The 12 January 2019 build (11552) is out.
« Reply #26 on: February 21, 2019, 03:02:20 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12069
    • Travis build status
Re: The 12 January 2019 build (11552) is out.
« Reply #27 on: February 21, 2019, 08:39:28 pm »
Can someone try to find why this problem happens?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2545
Re: The 12 January 2019 build (11552) is out.
« Reply #28 on: February 22, 2019, 10:49:13 am »
Quote
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...

Offline Miguel Gimenez

  • Regular
  • ***
  • Posts: 369
Re: The 12 January 2019 build (11552) is out.
« Reply #29 on: February 22, 2019, 11:34:40 am »
Quote
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?
« Last Edit: February 22, 2019, 11:37:04 am by Miguel Gimenez »