Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

[Dave F. <dav...@co...>]

On Thursday 25 March 2004 04:55 am, Patrick Earl wrote:
> I also like having one class per file, though I personally don't mind
> having small related utility classes in with the main one.  I used to
> hate that one class one file Java thing. ;)

Well, to go into more detail, I figure that a class that is only used in one 
place is perfectly ok being in that file as well (you'll see me do this 
occasionally).  But if a class gets used by two or more other classes, it 
should be pulled out and stuck in its own file.  That said, I also don't like 
source trees with a bazillion files, and all these files and classes in Jazz 
kinda get on my nerves.  I think we should take Fesic's advice and go 'back 
to the beginning'.  :)

> As to dialogs, one advantage of the "Attach" method is that different
> widgets can be handled automatically.  For example, you could attach
> a long* to a resource named "number".  The user would have the option
> of making "number" a wxTextCtrl, a wxSlider, a wxChoice, etc.

To be honest, I'm not particular on *how* the data is pulled from the dialog.  
I'm interested in this Attach method.  Also, bear in mind I just came back 
from php-land yesterday, so it'll take a little bit for me to get 
strongly-typed again.  :(  In any case, I was thinking that the absolute best 
way to take the most advantage out of XRC would be to have one single dialog 
maker using several different XRC dialog resources rather than just making a 
bunch of dialogs that all load their resources from a file.  It's entirely 
possible that the XRC system will take care of the whole problem of pulling 
data from the dialog for us.  I seem to recall that in XRC you define both 
the resource name and the type, placement, look, etc.  Maybe it just takes 
care of it for us?  ;)

> With the associative array, extra logic would be necessary to know if
> you want, for example, a string or a long.  It seems like there could
> be issues getting the data in the format you want without having to
> write much code for each dialog.

Not necessarily, but the associative array deal is far from perfect.  It is 
pretty readable, though, and that's a winning trait for it's use in 
weak-typed languages.

> I dunno, I'm sure the "Attach" system is far from perfect, but as far
> as I can remember, I haven't seen anything better.  I'd be interested
> in taking a look at the template thing if you happen to remember what
> it is.

It's just a template in STL.  I think you were right when you said it was a 
hash, map, or hashmap, or something like that.  You do:

std::hash<jppDialogData> *DialogData;

jppDialogData is a class you construct to store all the data in.  Or something 
like that.  I'm forgetting how the maps actually work right now.  :(

> BTW, here's an extremely rough comparison of the two techniques:
>
> // "Attach" technique.  This is actual code that would work in the
> // current system.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> dialog.Attach("myTextCtrl", &myString);
> dialog.Attach("myCheckBox", &myBool);
> dialog.ShowModal();

Is this "Attach" method part of wxWindows already?  It looks familiar....

> // Associative technique.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> if(dialog.ShowModal() == wxID_OK) {
>     myString = dialog.array["myTextControl"].asString();
>     myBool = dialog.array["myCheckBox"].asBool();
> }
>
> If the associative version were to be non-modal, it would require data
> manipulation code in both the Apply and Ok handlers.  I'm sure they
> could be combined somehow, but it still needs to run at some point.
> Switching the "Attach" one to non-modal would be as simple as running
> dialog.Show() instead of dialog.ShowModal().
>
> Please tell me if I'm missing some piece of the puzzle, but I honestly
> don't see that it gets any simpler than the first method.
>
> For the STL associative arrays, is it the map and hashmap?  As far as
> I know, those only take keys and values of one type... any type, but
> only one at a time.

Yes, but the type is user-defined.  You can give it a struct or a class, so 
you can actually store whatever data you want.  Build your class just right, 
and you can always extract it in whatever form you want.  I don't know if 
it's the best solution, though.  If it were PHP, it would be.  :)  (Or 
Python, heh.  Anybody want to port Jazz to wxPython?  Then we'd be finished 
with it tomorrow)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

He who has imagination without learning has wings but no feet.