Plug-in Issues

[Avan]

Hi,

When I create a new Plug-in Project I run into so many problems that I couldn't begin to describe them to anyone and in the end still make sense. I guess the simplest thing would be to create an empty plug-in and try to open and build it yourself.

What I noticed while using the Project Wizard:
- I have wxWidgets 3.1.3 installed but that does not seem to show up on all locations in C::B.
- There's no reference to wx31 in Build | Select Target and Project Wizard seems unaware of it sometimes.
- Linker default: $(#cb)\devel30 is used instead of $(#cb)\devel31_64 so no linking happens.

When I open the virgin plug-in in C::B I get this error, repeated many times when I keep clicking Ok.

...\wxWidgets\include\wx\strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

Building seems not to be hindered by the error but many of the files a not in the places the wizard thought of looking.

These issues must must be an error in my setup, but I cannot figure out what I did wrong at install or are doing wrong now. I can get all paths resolving and the project building to completion. But the next time around the same thing will happen.

I'm running C::B 12292, Win7.

Any thoughts?

[stahta01]

The wizard normally remembers the path you entered; try entering the correct path and it should remember it.
You entered the wrong path once and it now remembers it.
You need to verify the Global Variables are set correctly before running the wxWidgets wizard!

Tim S.

[Miguel Gimenez]

Excerpt from the script:

Code

        intro_msg += _T("\nVERY IMPORTANT NOTE:\n\n" +
                        "Code::Blocks is built with the GNU GCC compiler and links to\n" +
                        "the monolithic unicode wxWidgets DLL.\n" +
                        "This means that you must have exactly this setup to be able to\n" +
                        "build the generated plugin.\n" +
                        "You must also have defined two global variables:\n" +
                        "   1. $(#cb) pointing to Code::Blocks base dir (where CodeBlocks.cbp is)\n" +
                        "   2. $(#wx) pointing to wxWidgets base directory\n\n\n");

[stahta01]

So, it looks like the CB Plugin Wizard was never updated for 64 bit and maybe never updated for wxWidgets 3.1.
The user can edit the script to fix the problem; I have no plans to ever waste my time editing any wizard because I have already wasted 100 plus hours with no return!

Tim S.

[Miguel Gimenez]

When shown, the "VERY IMPORTANT NOTE" is truncated after "global", so the variables needed are not visible (see attached image).

Later, after selecting wxWidgets 3.1 it creates three targets:
  - default
  - to_codeblocks_wx28
  - to_codeblocks_wx30

IMHO the targets should be:
  - default
  - to_codeblocks_wx31

[Avan]

Excerpt from my monitor:

Code

                        Code::Blocks is built with the GNU GCC compiler and links to
                        the monolithic unicode wxWidgets DLL.
                        This means that you must have exactly this setup to be able to
                        build the generated plugin.
                        You must also have defined two global variables:

Hi Miguel,

The wizzard on my 12292 shows no further than the colon. Like I quoted it above. You got your exerpt from source code but that's not how it ends up.

Also, I find the concept of a 'base dir' rather confusing. As do others, I think I once read a convoluted recipe that made me set ../sdk as the base dir.

Any toughts on the warning I mentioned in my initial post?

(You beat me to it by minutes ;o)

[Miguel Gimenez]

When you say

When I open the virgin plug-in in C::B

are you referring to opening the created source code in the editor or loading the compiled plugin in C::B?

EDIT: what kind of plugin are you generating (generic/tool/MIME handler/wizard) and which options?

[Avan]

When you say

When I open the virgin plug-in in C::B

are you referring to opening the created source code in the editor or loading the compiled plugin in C::B?

EDIT: what kind of plugin are you generating (generic/tool/MIME handler/wizard) and which options?

The created source code, as that is the wizard's default action after Finish.

- Tool
- No configuation dialog
- wxWidgets 3.1.x
- GNU GCC Compiler

Now I press Finish and the wxWidgets Debug Alert follows immediately (stdvararg.h(451)) and I have to click Ok 9 times to get the plugin loaded.

[Miguel Gimenez]

Can't reproduce here, but I am using wx3.1.4 (32 bits, with default debug level 1). From About -> Information:

Code

Name             : Code::Blocks
Version          : svn-r12293
SDK Version      : 2.6.0
Scintilla Version: 3.7.5
Author           : The Code::Blocks Team
E-mail           : info@codeblocks.org
Website          : http://www.codeblocks.org

wxWidgets Library (wxMSW port)
Version 3.1.4 (Unicode: wchar_t, debug level: 1),
compiled at Jul 23 2020 11:26:42

Runtime version of toolkit used is 6.1.

EDIT: looks like C::B code uses %d to print a long. In 32 bits int and long have the same length, but not in 64 bits, hence the assertion. Can you get a stack trace?

[Avan]

Code

                        "   1. $(#cb) pointing to Code::Blocks base dir (where CodeBlocks.cbp is)\n" +
                        "   2. $(#wx) pointing to wxWidgets base directory\n\n\n");

I have set cb pointing to the folder trunk\src where codeblocks.cbp resides.
I have set wx, wx31 and wx31_64 pointing to \wxWidgets.

Now I create a clean Tool Plugin with a name I never used before and move to Project | Build Options | Search Directories (the plugin does not compile as is).

Search Directories | Compiler | default shows:
$(#wx31.include)
$(#wx31.lib)\gcc_dll\mswu

Search Directories | Linker | default shows:
$(#wx31.lib)\gcc_dll
$(#cb)\devel30

I change the latter to $(#cb)\devel31_64 and it builds.

The only thing realy wrong here seems the "$(#cb)\devel30" string as I have installed wx31_64.

The other issues here vanished when I had all wx-variables point to the same folder. I had figured wrongly that 'wx' was the generic variable which was going to make our lives easier when new wxWidgeds come along. I'll have to change all projects Build Options each time that happens. Bummer!

[Avan]

EDIT: looks like C::B code uses %d to print a long. In 32 bits int and long have the same length, but not in 64 bits, hence the assertion. Can you get a stack trace?

I'm using 3.1.3, that the only difference between our setups. I'll happily move to 3.1.4, as long that doesn't bother me with incompatibilities with the nightlies. Did it build right away or did you have to nudge it into place with a sledge hammer? ;o)

Can you even do a stack trace during plugin creation? That's the only place and time the message appears. Reopening the plugin does not trigger this (I have not ticked the "dont bother me again" box, in case you were wondering).

EDIT: And I use 64 bit and one release earlier but everything else on the printout from About is the same.

[Miguel Gimenez]

The change to wx3.1.4 is completely painless.

The assert is shown when the project is created, so the code must be in the wizard. Probably you can debug C::B from devel31 using C::B from output31 and break it when the assert appears; I would do it, but I can not reproduce the issue.

[oBFusCATed]

This is probably an explanation for the assert https://sourceforge.net/p/codeblocks/tickets/900/

[Avan]

This is probably an explanation for the assert https://sourceforge.net/p/codeblocks/tickets/900/

Found that bit of code. It appears _SQ64 is not defined here so the %lld would never be compiled.

#ifdef _SQ64
            result.Printf(_T("%s%ld"), str1.c_str(), sa.GetInt(2)); <-- This line is greyed out.
#else
            result.Printf(_T("%s%d"), str1.c_str(), sa.GetInt(2));
#endif

The only location I could find a #define _SQ64 is in squirrel.h and _WIN64 is defined in the Build Options.

#if (defined(_WIN64) || defined(_LP64))
#ifndef _SQ64
#define _SQ64
#endif
#endif

Can I count on C::B that if squirrel.h is somehow included then this line is correctly excluded? And should it be excluded in a 64 bit build?

BTW, I changed the next line to read %lld but noticed no differences in behaviour.

[Avan]

The change to wx3.1.4 is completely painless.

The assert is shown when the project is created, so the code must be in the wizard. Probably you can debug C::B from devel31 using C::B from output31 and break it when the assert appears; I would do it, but I can not reproduce the issue.

I'm not very familiar with C::B but I'm noticing behaviour that can't be right (like bookmarks not working) so I will first build 12293 and wx314 before I continu. Possibly there's a glitch somewhere.