User forums > General (but related to Code::Blocks)
xrc vs c++
takeshimiya:
XRC all the way, for the reasons stated above.
-Recompile time
-Interoperability: you can pass your XRC to a programmer of other language. It is RAD-agnostic, Platform-agnostic, and Language-agnostic.
byo:
In my opinion there's no simple answer for this question. I've been investigating XRC standard (and source code of xrc) for some time and in some cases XRC is better but in others c++ source.
One of biggest XRC adventages is that resource is separated from code. This can make development process little bit easier and organized better.
But... XRC doesn't handle everything - sometimes not all styles supported by widget can be used, sometimes there's no content-managment for widget, so You have to add it manually, and try to fetch pointer to sizer from resource ;). Ok, these things may change in near future since it's not hard to add support for in in xrc source code.
But there are some other things which need to be mentioned: XRC doesn't have support for event handling so it must be done in the code. And one more thing - usually source code assumes that resource has specified structure or that some widgets exist in resource. What if unexperienced user changes xrc file a little bit ? Application will usually break because instead of widget pointers there will be NULLs.
So IMO XRC is really god thing during development but it may not be a good option for releases where I suggest c++.
BTW. wxSmith currently doesn't allow switching between xrc and source code (it will be supported :)) but there's easy way to switch - close C::B, open wxsmith/wxsmith.cfg in text editor and for resources You want change edit_mode attribute for "Source" or "Xrc" than open C::B and change anything in resource to reproduce source code. That should work :)
One warning: some things (like pointers to sizers) may be lost when switching from Source to Xrc.
takeshimiya:
--- Quote from: byo on February 20, 2006, 11:08:30 am ---BTW. wxSmith currently doesn't allow switching between xrc and source code (it will be supported :)) but there's easy way to switch - close C::B, open wxsmith/wxsmith.cfg
--- End quote ---
byo, now that you say, I have two questions I wanted to ask:
-The .wxs files are straight .xrc files (sometimes you add/could add another tags), but as it's xml, I think the wx xrc loader shouldn't have any problem ignoring your (very little) new tags compared to .xrc files.
Having both .xrc and .wxs may seems no big deal, but it confuses newcomers.
I actually once experienced a bug in wxSmith where the .xrc gone out of phase of the .wxs, and it took me more than two hours to understand why it wasn't working. This could never happen if the xrc is edited directly.
-The wxsmith.cfg file. A minor issue compared to the one above. It's kinda a little project file, but I see that there could be three options:
1) Integrate it in the .cbp of the current user project.
2) Create a new .cbp only for wxSmith things.
3) Leave as is now, but improving it with versionating (more or less trying to be like a small .cbp).
So basically the current layout generated by wxSmith is as:
--- Code: ---dialog1.xrc
dialog2.xrc
project.cbp
wxsmith\
Dialog1.xrc
Dialog1.xrc
wxsmith.cfg
--- End code ---
and I think it could be something like:
--- Code: ---dialog1.xrc
dialog2.xrc
project.cbp
dialogs.wxsproject
--- End code ---
wxSmith is amazing. :D
byo:
--- Quote from: Takeshi Miya on February 20, 2006, 12:09:55 pm ---byo, now that you say, I have two questions I wanted to ask:
-The .wxs files are straight .xrc files (sometimes you add/could add another tags), but as it's xml, I think the wx xrc loader shouldn't have any problem ignoring your (very little) new tags compared to .xrc files.
Having both .xrc and .wxs may seems no big deal, but it confuses newcomers.
I actually once experienced a bug in wxSmith where the .xrc gone out of phase of the .wxs, and it took me more than two hours to understand why it wasn't working. This could never happen if the xrc is edited directly.
--- End quote ---
You're right, the content of generated xrc files is almost equivalent to wxs and duplicated data has always came with troubles sooner or later ;). And xrc loader doesn't have any problems with loading wxs files. Actually when You click preview button id loads wxs file using xrc loader and shows it.
But I've noticed that other editors have some problems when additional info is added to xrc. I'll think about the solution. My current idea is to have one strict xrc file and one other for additional stuff
--- Quote ----The wxsmith.cfg file. A minor issue compared to the one above. It's kinda a little project file, but I see that there could be three options:
1) Integrate it in the .cbp of the current user project.
2) Create a new .cbp only for wxSmith things.
3) Leave as is now, but improving it with versionating (more or less trying to be like a small .cbp).
--- End quote ---
I vote for option 1 :D. But AFAIK there's no support in cbProject for this currently. So currently I'll leave it as is and maybe after some feature request cbProject will support this :)
Thx for all suggestions :)
mandrav:
--- Quote from: byo on February 21, 2006, 08:51:26 am ---I vote for option 1 :D. But AFAIK there's no support in cbProject for this currently. So currently I'll leave it as is and maybe after some feature request cbProject will support this :)
--- End quote ---
Actually this is something I wanted to add for a long time now.
Good thing you reminded me. You can find it in revision 2052 ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version