wxSmith - validators everywhere, maybe...

[eranon]

Hello. I've seen (and used) the possibility to declare a validator for some controls since last C::B SVN... Nice feature : bravo !

But would it be possible to add this possibility for all controls, giving the developer all capacity to decide if he needs to use validator or not. For example, in my case, I've derived some validators for custom controls and also ones not covered by standard validators and I can't add them through wxSmith ; I have to attach them outside of wxSmith generated code.

[MortenMacFly]

I have to attach them outside of wxSmith generated code.

Why? The wxValidator field is just a text. So if you derived from wxTextValidator as wxMyTextValidator for example, just enter the derived class and that's it.

[eranon]

Hum, yes, of course, Morten, but maybe I've poorly explained what I've in mind. OK for the derived custom controls (well understood classname is free in wxSmith). But, back on case about some standard controls for which wxSmith doesn't show a validator field : for example, I've written a validator to handle data-tranfers to/from wxFilePickerCtrl, wxFontPicker and wxColourPicker. In the case of file-picker, wxSmith displays a validator field, but not for the font and color-picker cases...

Knowing SetValidator is a wxWindow's method, don't any UI control supposed to be able to be binded with a validator ; or did I missed a point ?

[MortenMacFly]

In the case of file-picker, wxSmith displays a validator field, but not for the font and color-picker cases...

In that case there is an issue with font- and color picker, not the validator. The validator property is a low-level property already and should therefore apply where appropriate. If you want to, you can have a look at the difference between FilePicker and the other ones to find out where the actual bug resides...

[eranon]

If I can help and according to my "beginning-level" knowledge of wxWidgets, of course, I could take a look where you tell me... But, maybe, as first-step checking : do you have too a lack of wxSmith's validator field about font and color-pickers in your own Code::Blocks ? This, simply to exclude case where my config would be in/the cause.

--
EDIT : checking after posting, I realize validator field well exists about wxColourPicker (don't know why I didn't seen it before). However, I still don't see any about wxFontPicker... I double-ckeck to be sure.... [some seconds]... I confirm : I don't see validator field for wxFontPicker

[MortenMacFly]

From having a quick comparison between wxsFontPickerCtrl and wxsColourPickerCtrl I can say the reason is clear:

Code: [Select]

wxsFontPickerCtrl::wxsFontPickerCtrl(wxsItemResData* Data):
    wxsWidget(
        Data,
        &Reg.Info,
        wxsFontPickerCtrlEvents,
        wxsFontPickerCtrlStyles,
        flVariable | flId | flPosition | flSize | flEnabled | flFocused | flHidden | flColours  | flToolTip | flHelpText | flSubclass | flMinMaxSize | flExtraCode)
{}
vs.:

Code: [Select]

wxsColourPickerCtrl::wxsColourPickerCtrl(wxsItemResData* Data):
    wxsWidget(
        Data,
        &Reg.Info,
        wxsColourPickerCtrlEvents,
        wxsColourPickerCtrlStyles),
        m_cdColour(*wxBLACK)
{}
shows that wxsFontPickerCtrl uses special flags which hides the validator flag and is actually most likely not what was intended. I wonder why this is the case (I didn't implement it).

Just adding (OR'ing) "flValidator" to this list should make it work, but requires you to build wxSmith yourself. However, I think a better way is to use the default flags and add what's needed in addition. For clarification: Usually, if you declare flags like that you want to add some non-default flags, but might also want to hide some default flags. I don't know what applies to wxsFontPickerCtrl to be honest... anybody?

[MortenMacFly]

...btw: The only controls that do such "hocus-pocus" are wxsFontPickerCtrl, wxsRichTextCtrl and wxsSimpleHtmlListBox. I think in all three cases the right solution is to remove those flags all-together from their implementation and therefore having applied the default flags. I don't see why this should be wrong, because from the list of flags they map the list of default flags except the validation. Nevertheless I believe all of these can have a validator... need to check with wxWidgets docs though... So I think this is a bug.

[eranon]

Thanks for this analysis which save me from headhache , Morten ! So, maybe it would be cool to submit a bug report towards the wxSmith's author (Byo, if I've well understood from others threads I've read)...

By the way, what's the official place to download the wxSmith's source code ? Is it this one : http://sourceforge.net/scm/?type=svn&group_id=320287 ?

[MortenMacFly]

So, maybe it would be cool to submit a bug report towards the wxSmith's author (Byo, if I've well understood from others threads I've read)...

Byo is no longer active, I'm afraid. Also, I believe these additions came from another developer.

So, maybe it would be cool to submit a bug report By the way, what's the official place to download the wxSmith's source code ? Is it this one : http://sourceforge.net/scm/?type=svn&group_id=320287 ?

Nope, they are integrated into C::B's core SVN repository (http://svn.berlios.de/wsvn/codeblocks/?op=log&rev=0&sc=0&isdir=1). Just the one you use when you want to tom compile C::B yourself.

What I can offer - if you are willing t': If you give the modifications I described a try and report back if its working, I can commit these changes into SVN.

[eranon]

Oh ! oops... So, does it means future wxSmith will be taken in charge by the main C::B dev. team ? Hoping it will be not "abandonned".

If you give the modifications I described a try and report back if its working

Not sure what you mean, Morten (remember I'm French and can miss some English subtleties - lol) : do you wish I add "flValidator" in the wxSmith source, then rebuild the DLL and try if it works ? Or do you prefer to send me a patched DLL directly ?

[MortenMacFly]

Oh ! oops... So, does it means future wxSmith will be taken in charge by the main C::B dev. team ? Hoping it will be not "abandonned".

No, don't worry. In fact since Byo left the team there has been a lot of improvements already. He was "just" the initial coder.

do you wish I add "flValidator" in the wxSmith source, then rebuild the DLL and try if it works ? Or do you prefer to send me a patched DLL directly ?

No, I meant to remove the line like this:

Code: [Select]

wxsFontPickerCtrl::wxsFontPickerCtrl(wxsItemResData* Data):
    wxsWidget(
        Data,
        &Reg.Info,
        wxsFontPickerCtrlEvents,
        wxsFontPickerCtrlStyles)
{}
Then compile and run. I cannot provide you with a DLL - mine is incompatible to i.e. nightlies.

Maybe one of the other devs reading this has an objection - if not, I can also just commit after a while of testing and then you'll get this functionality with the next nightly.

[eranon]

OK, ouf! ("phew!" in English according to Google translate) for wxSmith

Well, I've checked out "svn://svn.berlios.de/codeblocks/trunk", then loaded "CodeBlocks.workspace" in C::B and selected wxSmith as active project. Well located the code line to modify, but firstly I would like to succeed to build as it is. So, from this point, I've selected the named "wxSmith" target (seems to build the DLL going through GCC compile) and clicked "build"... And I receive these 4 linkage errors (see attached screen-capture) :

cannot find -lwxpropgrid : where does this comes from ?

- cannot find -lwxmsw28u : oops ! Since I've fully switched to 2.9.3, I've deleted all wxWidgets 2.8 tree... Well, I could rebuild, but I would like to be sure to succeed linkage against C::B project at first attempt : so, is there some special GCC options I should take care ?

- cannot find -lcodeblocks : is it because I've to build entire C::B rather ?
- cannot find -lwxsmithlib : is it because I've to build the "wxSmithLib" target before ?

[dmoore]

eanon: you have to build C::B itself. activate C::B main project file, make sure target is set to all and then build it. you will also need the wxSmith lib and wx2.8. (Don't think CB is quite ready for 2.9, but close)

[jens]

(Don't think CB is quite ready for 2.9, but close)

C::B core is, and I have patches fr the most contrib-plugins (including wxSmith).
But the patches just make it possible to compile the plugins, real testing is not (yet) done, because not all plugins compile at the moment (currently I work on wxSmith-ContribItems).
I hope to get first results this week, probably the next weekend.

[MortenMacFly]

And I receive these 4 linkage errors (see attached screen-capture) :

You should read the WiKi section ("nightly cookbook" or alike) on building C::B.

What needs to be done first is to compile wxwidgets (thaths a one-liner, but long process)
 and then compile the whole workspace of C::B - wxSmith depends on the C::B core.

Alternatively you should also be able to link against the DLL's provided with nightlies. In that case its enough to open the wxSmith project file and maybe adjust the path's for the linker. This avoids compiling wxWidgets and C::B core.

[MortenMacFly]

...or just wait for the next nightly:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=8244&peg=8244

[eranon]

OK, read all your replies Well, I've launched build of wxWidgets 2.8.12 using TDM-GCC... Now, I've to wait, and awaiting I'm reading : http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows... I'll tell you the result !

--
EDIT : OK, build wx 2.8.12, then built C::B SVN 8245. At this step, I've seen wxsmith DLL was absent under "devel\share\CodeBlocks\plugins", so I've built the wxSmith project itself...

Also, I've noticed the block part to change in source has been effectively made (as you show me above too, Morten) since my last post here. Tortoise confirm (see image)... So, nothing to do for me in code, but just to test if it's working here (or not ; lol).

This done, I've added wxmsw28u_gcc_custom.dll beside "devel/codeblocks.exe", then clicked to launch C::B devel. Then, loaded a test project in which I've added a wxFontPickerCtrl using wxSmith editor.

And, as you can see in the attached screen-shot, it works : font-picker has now a validator field Tested OK !