Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Trying to build callswizard plug-in (help needed, got stuck)

<< < (2/3) > >>

killerbot:
So it seems that more of us are running into problems.
Let's hope Yiannis can shed some light on this issue.

From my experiments it has to do with wxWidgets.
And most probably the moment you are using dialogs.

Since my MatchinBrace plug-in still works (recompiled and a minor change in the code), the only thing it does wrt wx , is adding some menu entries and talking with scintilla objects.

In my other plug-in for ClearCase everything works fine, untill I added my first dialog. There all my problems started. Because I was not sure if I did everythingcorrectly, I decided to rebuild a core plug-in(class wizard). And the problems remain.

Now for using a library, you need header files (downloaded from wxWidgets : 2.6.1), so I guess these are OK, and import library.
Now some areas where the problem can be originating from :
 - the headers being included are behaving differently by lack of, or by having extra, preprocessor defines
 - different setup.h (which contains eg version strings for wx : this file is the result of building wx !!!)

On the subject of what (sh)(c)ould be belonging to the sdk : import libraries for the used dll's in cb, for sure setup.h !!!
And maybe a little note telling which preprocessor defines should be issued/provided.

Hope we crack this issue soon  :wink:

Lieven

mandrav:
One possible thing to check is that you 're not having other wx DLLs lying around in the system paths (e.g. in \windows\system32). The point is that the same wx DLL must be used by the app *and* the plugins.

Because you 're having problems when adding a dialog, this indicates trouble with the message (modal) loop. This can be caused by a plugin linked statically to wx or using the wrong wx DLL...

This is the reason C::B only works with wx as a DLL and not as a static lib. It needs to have *only* one main message loop.

I 'll repeat this here once again:
In a "clean" machine (i.e. nothing programming-related installed) everything works as expected.
In my development machine, everything works as expected (obviously :P).

If you 're having trouble, start by deleting every wx DLL you have lying around, except wxmsw26_gcc_cb.dll in codeblocks folder...

Use these options (not all are needed, but I 'm giving the exact same options I use):

--- Code: ---Compiler:

-Wall
-g
-pipe
-mthreads
-fmessage-length=0
-fexceptions
-DHAVE_W32API_H
-D__WXMSW__
-DWXUSINGDLL
-DcbDEBUG
-DTIXML_USE_STL
-DBUILDING_PLUGIN

Libs:

libcodeblocks.a
libwxscintilla.a
libwxmsw26.a

--- End code ---

As far as wx/setup.h is concerned I haven't edited it.

Pecan:
killerbot

I applied the patches for wxWidgets 2.6.1 Now all is working well.
I also re-compiled ClassWizard, and it also works fine with
the patches.

wxWidgets Patches
Patches for 2.6.1. Various wxMSW fixes. This patch fixes the following problems
... Please download wxWidgets-2.6.1-Patch01.zip and unarchive from the top ...
www.wxwindows.org/patch.htm - 6k - Cached - Similar pages

ftp://biolpc22.york.ac.uk/pub/2.6.1/wxWidgets-2.6.1-Patch01.zip

I noticed that some of the headers (window.h etc) are used
all over the place.

Thanks
Pecan

Zlika:
Great news! I'll test it quickly.
You should update the wiki ("Compiling wxWidgets 2.6.1 to develop Code::Blocks" tutorial) with this critical information!

killerbot:
Pecan,

Excellent, I am able to build the class wizard AND have it running without crashing.
Many thanks for your solution !!!

I am glad to know that I did not screw up with import lib's and dll's, I was very sure I was doing that part correctly.

Since during the build of plug-in dll, the only references to wx are the header files, the problem should be in one of those.
The patch contains new versions of :
.cpp (should be of no importance to our issue) :
  window.cpp
  tbar95.cpp
  splitter.cpp
  notebook.cp
  helpchm.cpp
  grid.cpp

.h (the problem was probably in here)
  listbox.h                 (2 changes, from which 1 code change)
  notebook.h            (seems to be unchanged)
  uxthemep.h           (1 change / different include)
  window.h              (2 changes, from which 1 code change)

The generated setup.h is identical.


Just an idea :
Maybe we could have some people testing the sdk part of the delivery, a test suite could be : compile all build-in plug-ins by using the sdk. We do need for every plug-in then a cbp project file, preferably as minimal as possible.
So compiler switches and include paths which are not needed should be out of the cbp. This way thinks become more clearer, and one get's more focus on the thing that do matter.
You can count me in for such a testing group.

And indeed the wiki needs to be updated to contain this kind of information. Do note, that the wiki entry is going all te hawy, even building cb, and then maybe the problems won't happen, since then everything is really using the same sources, dunno ??


Change for window.h : added
    // some controls (e.g. wxListBox) need to set the return value themselves
    //
    // return true to let parent handle it if we don't, false otherwise
    virtual bool MSWShouldPropagatePrintChild()
    {
        return true;
    }

Change for uxtheme.h :
#include <commctrl.h>   
  becomes
#include "wx/msw/wrapcctl.h"

Change for listbox.h : added
    // under XP when using "transition effect for menus and tooltips" if we
    // return true for WM_PRINTCLIENT here then it causes noticable slowdown
    virtual bool MSWShouldPropagatePrintChild()
    {
        return false;
    }


What do the core developers think of this, ensuring to get an ever better usable sdk ?

kind regards,
Lieven

Navigation

[0] Message Index

[#] Next page

[*] Previous page