Author Topic: Docking library  (Read 28452 times)

SnakeChomp

  • Guest
Re: Docking library
« Reply #15 on: August 22, 2005, 05:27:46 am »
Here is what I have come up with after some work: www.snakesoft.net/wxifm/images/wxifm.png. Unfortunately a wxWidgets bug is preventing me from completing another thing I wanted to do tonight, which is to dynically show or hide the caption of a floating window depending on how many children it has. I can add a caption just fine but it never goes away again.

Edit
Looks like I spoke too soon, it was my codes problem, not wx's.
« Last Edit: August 22, 2005, 05:34:10 am by SnakeChomp »

SnakeChomp

  • Guest

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #17 on: August 27, 2005, 11:23:34 am »
Damn! Man, you really wanna make us switch, don't you?
Well, you 're making a great job with it :P :D

I will definetely check out this 1.0.4 version.

Just to avoid confusion:
The reason I pospone checking wxIFM within C::B is that C::B would need an overhaul to support it correctly (mainly because the tab panels we use expect a wxNotebook as a parent, while with wxIFM it could be any wxWindow, right?). Not that major but still...
I sure plan to embed and test it though. I don't think it should be *that* hard...

Yiannis.
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #18 on: August 27, 2005, 11:35:39 am »
The tab panels would be children of the main frame (or a floating window). There wouldn't be any more notebooks anywhere (except for document windows). Why do your tab windows assume their parents are notebooks right now anyhow?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #19 on: August 27, 2005, 12:29:47 pm »
The tab panels would be children of the main frame (or a floating window). There wouldn't be any more notebooks anywhere (except for document windows)

That's what I figured. Thanks :)
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #20 on: August 27, 2005, 12:45:24 pm »
SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #21 on: August 27, 2005, 01:39:45 pm »
SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?

Like I thought: doesn't work...

Anyway, I 've patched the sources to allow for mixed-environment compilations, i.e.:
wx DLL, IFM static
wx DLL, IFM DLL
should also work with wx static and IFM [DLL|static], but I haven't tested it...

Attached is the patch and C::B workspace for wxIFM (extract in top-level wxIFM folder).

[attachment deleted by admin]
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #22 on: August 27, 2005, 10:17:50 pm »
Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #23 on: August 27, 2005, 11:05:25 pm »
Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

You see, the point is that it works for you, but not for me.
* I 'm talking about gcc compilation
* I don't like any kind of warnings in my code (neither should you).
* "I get a tons of warnings but I don't care as long as it works" is not a good response at all, if you don't mind...

I 'm not talking about wxIFM as a DLL itself. I 'm talking about static wxIFM with wxWidgets DLL. The thing is that WXUSINGDLL must be defined but if you use WXDLLEXPORT in wxIFM, it will wrongly use declspec(dllimport) when building it.
Also, you haven't exported any classes, except for that one using WXDLLEXPORT. Gcc doesn't like it. It builds the library (with many warnings) but chokes when trying to build the demo which uses it...

The patch I sent you, fixes all those issues (check only if the static wx case works).

If the patch doesn't work, you have three options:
a) use a command-line patch utility
b) check why it doesn't work. I can guess: I made this patch *outside* wxIFM dir. This means a simple search for "wxIFM\" and replacing it with "" should make tortoise happy...
c) ask someone to help you

Everything contributed to you, you should learn to accept it happily. Phrases like "Tortoise SVN doesn't like that patch so its pretty useless to me." should really be avoided...

Yiannis.
Be patient!
This bug will be fixed soon...

grv575

  • Guest
Re: Docking library
« Reply #24 on: August 28, 2005, 02:12:43 am »
It's a standard patch.
cd wxIFN/
patch -p1 -i ../wxifm.diff

tortoise may have the option to remove prefixes (-p1 removes 1 prefix [directory portion])?
otherwise just do the above in MSYS or cygwin

SnakeChomp

  • Guest
Re: Docking library
« Reply #25 on: August 28, 2005, 03:49:34 am »
Sorry. I went and got GnuWin32 patch and managed to figure out how to apply it. I had to add more WXIFM_DECLSPEC to some base classes that you didn't add them to as I was getting warnings about the derived class being exported while the base class was not. I'm only going to support build configurations where either wxWidgets and wxIFM are both statically linked, or they are both dynamically linked. (Using static wxIFM and dll wxWidgets "should" be ok but I haven't tried it) I tested all of these configurations (going through much pain due to the joy of the wx build system) and they all work except a strange problem with the release dll configuration. It crashes somewhere inside of wxmsw26_ifm.dll before the program displays anything. This doesn't happen for any other build so I am not going to bother wasting my time trying to figure out what exactly is going wrong. Another thing to note is that the wx bujild system fails during DLL builds because the "qa" project does not output any .lib files during dll builds. The wx headers force all programs to link against the qa .lib files, but the linker can't find these files (because the build system didn't make the file) so the builds fail. I had to modify my include/msvc/wx/setup.h to not force linking against these files for builds to complete succesfully. I have an oldish version of the 2.6 series so that might have something to do with it but I'm not going to bother with it anymore.

I dont think I'll be releasing another patch just for this change because it hardly effects anybody using wxIFM (nobody uses dll wx builds unless they have a very specific requirement to do so, like you do) and I haven't actually tried writing a plugin that uses symbols exported by dll versions of wxIFM. For all I know it may not really work at all and in that case dll builds of wxIFM are just as pointless as dll builds of wx.

I attatched a patch which has the modifications I made (remove the .txt extension). It is patched against 1.0.4, not against your changes, but it includes your changes. Note that I changed the name of the symbols you chose to identify a dll build of wxIFM. Those now being: IFM_DLL and IFM_BUILDING. IFM_DLL is defined when you are using the dll version of wxIFM and IFM_BUILDING is defined when you are building the wxIFM library. I haven't touched the makefiles so if you modified them to build dll versions of wxIFM you'll need to change them again. The makefiles aren't that good anyway, but I don't do makefiles so I couldn't make them any better myself.

[attachment deleted by admin]
« Last Edit: August 28, 2005, 04:00:49 am by SnakeChomp »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #26 on: August 28, 2005, 09:55:13 am »
Alright. On with testing now  :lol:
Be patient!
This bug will be fixed soon...

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: Docking library
« Reply #27 on: August 28, 2005, 03:47:43 pm »
Wow, I've just looked into wxIFM demo. And it has almost all features I would like to see in C::B... especially grouping in tabs - one of my favorite features in Visual Studio - just put everything where You like it to be :) now it can be done in my favorite IDE :)...
The only thing I would like to have is to easily order tabs by dragging it. But even without it, it will be great to see C::B cooperating with wxIFM ;).

grv575

  • Guest
Re: Docking library
« Reply #28 on: August 28, 2005, 09:13:22 pm »
Neat demo.  It builds with codeblocks.  I'm using the dll version of wxWidgets 2.6 and wxIFM as a static lib.  Steps:

1.  Build wxWidgets 2.6 according to the wiki:
http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_2.6.1_to_develop_Code::Blocks_%28MSW%29#Building_wxWidgets_2.6.1_mingw32_.26_vc.2B.2B_toolkit_2003
under "for vc++ toolkit 2003 compiler"

2.  Download wxIFM 1.0.4
http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?p=16704#16704
2b. and this patch:
http://forums.codeblocks.org/index.php?action=dlattach;topic=748.0;id=84 (reply #25 of this thread)

3.  Extract wxIFM source and patch it
open MSYS (download from mingw sourceforget site if needed), and do
cd wxIFM
patch -p0 -i ../wxifm_diff.patch.txt

4.  open codeblocks and import the .sln.  You will need to add some paths, enable c++ exceptions option, and also the WXUSINGDLL define.  Then build wxIFM and then the demo.  I've attached the modified .cbp codeblocks files.  You will need to modify any absolute paths as needed if you use these.  I only changed things for the nonunicode release builds as wel...

4b. if you want to link against msvcrt.dll instead of libc.lib (you can choose in the compiler options (MT DLL runtime lib or MT runtime lib) then do this to produce msvcprt.lib:

open MSYS
cd /c/WINDOWS/system32
PATH=$PATH:/c/Program\ Files/Microsoft\ Platform\ SDK/Bin/win64/
echo LIBRARY msvcp71.dll > msvcprt.def
echo EXPORTS >> msvcprt.def
link -dump -exports msvcp71.dll | sed -nf exports.sed >> msvcprt.def
link -lib -machine:X86 -def:msvcprt.def -out:msvcprt.lib
exit

---exports.sed---
# echo LIBRARY msvcp71.dll > msvcprt.def
# echo EXPORTS >> msvcprt.def
# link -dump -exports msvcp71.dll | sed -nf exports_alt.sed >> msvcprt.def
# link -lib -machine:X86 -def:msvcprt.def -out:msvcprt.lib
#
/[ \t]*ordinal hint/,/^[ \t]*Summary/{
 /^[ \t]\+[0-9]\+/{
   s/^[ \t]\+[0-9]\+[ \t]\+[0-9A-Fa-f]\+[ \t]\+[0-9A-Fa-f]\+[ \t]\+\(.*\)/\1/p
 }
}
---end exports.sed---

the above should be saved as exports.sed (and make sure it uses linux line endings...vi exports.sed and check that there are no ^M at the end of the lines.  Shift-ZZ to get out of vi...).

now just put the generated msvcprt.lib and msvcprt.exp in your lib path: e.g. c:\program files\platform sdk\lib
(there's a similar trick to produce libmsvcrtp.a which gcc would need.  i just tried wxIFM with msvc toolkit since it had .sln stuff already.  google for the mingw exports.sed procedure it if needed)

5.  the demo outputs to c:\.  move c:\demo1.exe to wxIFM\samples\demo1 and launch it (copy wxmsw26_vc_cb.dll to the same directory or c:\windows\system32 if not already reachable somewhere in your path).


[attachment deleted by admin]
« Last Edit: August 28, 2005, 09:21:38 pm by grv575 »

Offline peso

  • Multiple posting newcomer
  • *
  • Posts: 12
    • Abalone on Wikipedia
Re: Docking library
« Reply #29 on: December 28, 2005, 10:21:12 pm »
Hi guys.

Have you checked wxAUI out?

http://wiki.wxwidgets.org/wiki.pl?WxAUI