[feedback] Latest rev.

[SlimFast]

I tried again with r5926 and I'll post my suggestion here, step by step:

Project setup:
Its still not convenient that one has to choose a virtual folder but is unable to create it when setting up a dialog (frame...). All the text entered is lost because you have to close this dialog. Why can't I create a virtual folder directly in the "select" dialog? (And btw: I was again searching where the heck one can create virtual folders. I had just created a workspace w/o a project and then you find n reference at all. OK - my fault, but I wanted to just create a GUI, no executable so far... like in wxFormBuilder.)

The UI still has some free space that could be used for flags to show (i.e. I always have scrollbars for the sizer flags), as you see in the attached image.

The rest was pretty smooth - I tried more complex controls like wxSTC and alike, it works very nice. I also like the way you setup bits a pieces for controls.

One thing I noticed is that if you don't use sizers with a border, the red line you show that surround the currently active control is often not, or only partial visible. Therefore it is of not much help. Maybe you could always sacrifice a pixel for that (you still have the preview for exact sizing).

In the preview the colours look a bit strange and not as what it gets when I compile the app (see screenshot #2). Why?

Another thing I noticed is that I was able to place controls above each other... at least in the preview (see screenshot #3). Maybe I did something wrong.

The rest again went very smooth. I created a tine editor with load/save menu and a few toolbar buttons... no issues. Nice work!

BTW: I noticed that this version takes way longer to start-up and shutdown (!) on Windows than the previous. Why?

[eranif]

Its still not convenient that one has to choose a virtual folder but is unable to create it when setting up a dialog (frame...).

You must choose a virtual folder - otherwise codelite will not be able to place the generated source files

but I wanted to just create a GUI, no executable so far... like in wxFormBuilder.

Its not wxFB. Its a codelite plugin, this means: it is tied to the workspace

The UI still has some free space that could be used for flags to show (i.e. I always have scrollbars for the sizer flags), as you see in the attached image

This is how wxPropertyGrid works - about the free space in the picture - this is how wxPropertyGrid works. If you select an entry in the wxPG its description will be displayed at that free space

One thing I noticed is that if you don't use sizers with a border, the red line you show that surround the currently active control is often not, or only partial visible.

Without a border the selection is "off" - limitation of the current implementation.

Another thing I noticed is that I was able to place controls above each other... at least in the preview (see screenshot #3). Maybe I did something wrong.

I assume you mean the 'wxStaticBoxSizer' - this is a bug in wxWidgets XRC handling of wxStaticBoxSizer. To workaround it - place a control inside the wxStaticBoxSizer and it will re-position itself
OR - enable the style flag: wxRESERVE_SPACE_EVEN_IF_HIDDEN

BTW: I noticed that this version takes way longer to start-up and shutdown (!) on Windows than the previous. Why?

I am not sure, it starts pretty instantly for me..

Eran

[SlimFast]

Thanks for the answers, please le me clarify one thing:

Its still not convenient that one has to choose a virtual folder but is unable to create it when setting up a dialog (frame...).

You must choose a virtual folder - otherwise codelite will not be able to place the generated source files

I know that I have to choose a virtual folder - that's fine. What I meant is that in the wizard it would be nice to have the opportunity to actually create the virtual folder directly w/o having to leave the wizard. That's what I think would be convenient.

Thanks for the hint with the static box sizer! I didn't know about this wx bug.

Meanwhile I have played a little more with it, including to import several XRC resources:

- Am I right that importing XRC resources is a one-way, i.e. once imported and changed inside CodeLite I cannot export/save is as XRC again?
- When importing XRC files that have a custom objects (because in my app I have a special XRC handler for this to work) simply nothing happened. No error message - just nothing. I took em a while to figure out the actual error as you can imagine. So my complain would be to be more descriptive and don't leave the user in the dark. (BTW: IMHO This also affects several other areas in CodeLite, for example look and how menu menu entries buttons are enabled and do simply nothing if you have no workspace/project - but that's another story).

The rest worked smoothly, even complex XRC files I was able to import and modify. Nothing more to say - very nice!

A final question: When importing an XRC file, a new wxcp file is created. Is there a possibility to re-use an existing (i.e. for panels of a notebook), or what is the concept? Do I always have a 1:1 relation between a UI resource and a wxcrafter resource file?

[SlimFast]

...on more thing, because it just happened:
I was editing the wxcrafter UI and is was "dirty". Then by accident I pressed ALT+F4 -> CodeLite closed w/o warning. after re-opening the project all last modifications were lost.

CodeLite really should warn about an unsaved resource on shut-down, especially for such complex stuff like UI's.

[eranif]

I know that I have to choose a virtual folder - that's fine. What I meant is that in the wizard it would be nice to have the opportunity to actually create the virtual folder directly w/o having to leave the wizard. That's what I think would be convenient.

This is a good idea, and is more a codelite issue and not wxCrafter (the 'virtual folder selector' dialog is part of codelite's sdk) - I will fix this (i.e. allow creating a virtual folder using the selector)

- Am I right that importing XRC resources is a one-way, i.e. once imported and changed inside CodeLite I cannot export/save is as XRC again?

Actually, wxCrafter is using XRC for displaying the preview and the designer, so you can actually use the files under ~/.codelite/wxCrafter or %appdata%\CodeLite\wxCrafter

When importing XRC files that have a custom objects (because in my app I have a special XRC handler for this to work) simply nothing happened. No error message - just nothing. I took em a while to figure out the actual error as you can imagine. So my complain would be to be more descriptive and don't leave the user in the dark. (BTW: IMHO This also affects several other areas in CodeLite, for example look and how menu menu entries buttons are enabled and do simply nothing if you have no workspace/project - but that's another story).

Thanks for the feedback

The rest worked smoothly, even complex XRC files I was able to import and modify. Nothing more to say - very nice!

The compliments should go to DavidGH since he is the one implemented XRC and wxFB importing

When importing an XRC file, a new wxcp file is created

Yes, you can not import them into an existing one (for now)

Do I always have a 1:1 relation between a UI resource and a wxcrafter resource file?

If you create new controls (not importing them) then you can have multiple forms per wxcp file - no problem there. Or you can choose to have 1 wxcp file per 1 form
There are pros and cons:
- Pros: you unified all the generated code into a one big cpp /h file and all images are also placed inside a single *_bitmap files, less files means faster compilation time
- Cons: changing a single form (dialog, panel, wxwizard or wxframe) can trigger a big rebuild (since all the subclass are including the same header file)

CodeLite really should warn about an unsaved resource on shut-down, especially for such complex stuff like UI's.

Indeed, sounds like a bug to me

Eran

[DavidGH]

Hi,

- When importing XRC files that have a custom objects (because in my app I have a special XRC handler for this to work) simply nothing happened.

Custom controls should import successfully (though there are still problems generating C++ code afterwards).

Could you post (or send direct to me) an example where import fails?

Regards,

David

[eranif]

SlimFast wrote:
- Am I right that importing XRC resources is a one-way, i.e. once imported and changed inside CodeLite I cannot export/save is as XRC again?

Actually, wxCrafter is using XRC for displaying the preview and the designer, so you can actually use the files under ~/.codelite/wxCrafter or %appdata%\CodeLite\wxCrafter

I was probably day dreaming when I wrote that...

codelite offers XRC export as well:
The generate code button (grey gear button) as a little drop down, if you open you can check the option to generate XRC as well as C++

Eran

[SlimFast]

Thanks for the feedback...

Hi,
Could you post (or send direct to me) an example where import fails?

Its actually very simple: I have a custom control named "wxNoBorderDialog", derives from wxDialog for this, in one of my apps where I am using it inside XRC files I wrote a handler for that.
So, you can take any XRC resource you have based on a wxDialog and just replace the top-level element with "wxNoBorderDialog" and then try to import it.

Maybe to stress again: I am not complaining it doesn't import (surely wxCrafter cannot know about this XRC element), but I am complaining that you don't get any warning/feedback at all. I had simply forgotten that I changed the top-level element (my fault not to look into the XRC before importing it). So I was lost for a while wondering why all XRC's are imported, but this one. But hey - maybe I am a but nut-picking though...

codelite offers XRC export as well:

Very nice! I'll play with that a little more.

BTW: When I saw the changes in SVN concerning the virtual folder thing I felt a little guilty. I didn't expect this to be such a massive change. I thought its just a button with a call to an already existent SDK function. Hopefully you didn't loose too much time for other, more important things.

[DavidGH]

Hi,
Could you post (or send direct to me) an example where import fails?

Its actually very simple: I have a custom control named "wxNoBorderDialog", derives from wxDialog for this, in one of my apps where I am using it inside XRC files I wrote a handler for that.
So, you can take any XRC resource you have based on a wxDialog and just replace the top-level element with "wxNoBorderDialog" and then try to import it.

I see. You've created your own handler for the derived dialog, instead of using the much simpler 'subclass' method. As you say, wxCrafter can't know anything about that new handler.

Out of interest, did you try the 'subclass' method? I've always found it sufficient for my dialogs, and wxCrafter does import it without difficulty.

[SlimFast]

I see. You've created your own handler for the derived dialog, instead of using the much simpler 'subclass' method. As you say, wxCrafter can't know anything about that new handler.

True, but it should at least tell me that and not just silently do nothing.

Out of interest, did you try the 'subclass' method? I've always found it sufficient for my dialogs, and wxCrafter does import it without difficulty.

Well to be honest I never tried. I chose the way as described above because I found an explanation in the wxwidgets forum / WiKi that time I needed it. As it was/is working I never touched it since. Maybe I'll try sub-classing. But this project has no high priority for me - its just a private tool that shall work and not be perfect.

Getting a little off-topic now, but where can I read about sub-classing in XRC files? Is this do-able in wxCrafter? (I think so - if you mean the custom controls, right?) I am trying to get the wording right... what is what...?!