Controls

[Ionic Wind Support Team]

I've been working on dialogs and controls this week.  Kind of stuck on how exactly I want to impliment creation and manipulation of controls.

In my previous languages I used a generic CONTROL statment that could add a control to a window or dialog template in one easy function.  Convenient, yes?  I have always liked the simplicity of it.  It does have its drawbacks though.  I have to manually add each control type to the function which precipitated the creation of ControlEx.  It also is a little bloaty code wise.  Having separate functions for manipulating each different control type led to a fairly large command set. 

Aurora gives us more power and along with that power more ways to solve the problem.  So I thought I would present a few of the ideas and get feedback from the alpha users.

#1.  We could just use classes and resource scripts.   Classes can be created dynamically with NEW and added to a window or dialog. The resource script would be output by the GUI editor to be included with a project.  The dialog class would have a function to load the resource.

dialog mydialog;
mydialog.FromResource("aboutdlg");
mydialog.DoModal();

window mywindow;
button closebtn;
....create the window
closebtn.Create(35,105,40,20,"close",BTN_DEFAULT,1,mywindow);

#2. We could have a Generic AddControl method as part of the window class.  Since a dialog inherits from window it would work with any derived class.  And then use separate classes for manipulation;

button closebutton;
mywindow.AddControl(CT_BUTTON,35,105,40,20,"close",BTN_DEFAULT,1);
button.Attach(mywindow.GetChildHandle(1));
button.SetText("Close me");

#3. We could have a bunch of methods in the window class.  And the usual classes for manipulation.

mywindow.ButtonControl(35,105,40,20,"close",BTN_DEFAULT,1);
myWindow.EditControl(20,20,208,40,"Edit 1", ED_MULTILINE,2);


Or perhaps one of you has a different idea.

Paul.

[Zen]

I think just from first thoughts i like the first idea best. I really dont like the third though. But thats just my preference.

Lewis

[ThadMiller]

Well, I'm not an alpha user (yet), but I think something like the code below is easy to read...

Code Select Expand


Def myButton as button = myDialog.CreateButton(35,105,40,20,"close",BTN_DEFAULT)

//or perhaps a single create function

Def myButton as button = myDialog.Create(CT_BUTTON,35,105,40,20,"close",BTN_DEFAULT)


... but I don't know how it would work with Aurora - that method is more of an OOP method, but from sample Aurora code I've seen, controls seem to get an ID within the window/dialog and aren't really objects themselves.  Just my 2 cents.

-Thad

[Zen]

Like Paul said only trouble with doing it that way is there is a lot of coding to be done for a single control creation function. Im not really fussed though. I can adapt.

Lewis

[Steven Picard]

I like option #1 the best.  Thad's idea is a good one but I think #1 will be the best in the long run.

[Bruce Peaslee]

I'm not far enough along to have an opinion except to say that I prefer speed, flexibility, and readability.ÂÃ,  ÂÃ, 

[seberbach]

I like the idea of having the "create" (and destroy) be a method belonging to the button you want to create.  Should it be created independent of where it is put?

I don't like the idea of REQUIRING the parent to "create" a control, (as option 3 implied to me) but I suppose it should be able to both create and destroy them.. the parent could "ask" the buttons to create or destroy copies of themselves specially for each parent which "wants to" create them. That way, you would not have to do it al againl each time you created copies of a parent.

Specifying which window is the parent inside the create or creating then "adding" the button as a method of the parent window.....

I'm not expert enough to suggest, but the idea of one instruction instead of two appeals, as long as it doesn't limit you in some way I haven't thought of yet.
If the parent has a control creating method, it could just say "me" for the parent's name.




Steve

[Parker]

I like being able to define them with CONTROL without having to have a new object for each one, although having a button class would be nice, maybe a CONTROL command could come later that just calls the proper class, it shouldn't be too hard, would it?

[GWS]

Ooo .. er .. that is .. cough ..

I'm still readingÂÃ,  but I'm finding all this class stuff incredibly verbose from the user's point of view.

The thing that made IB so popular was the user's ability to create a Window or any type of control with a one line statement.ÂÃ,  I appreciate that things probably aren't so simple behind the scenes.

While still maintaining the ability of using OOP for applications that would benefit from it, could we cling to the simple approach (for the user that is) ..ÂÃ, 

Graham

[ThadMiller]

I suppose I don't really understand the concept behind creating a control that doesn't belong to a window, but then, I don't claim to be an expert windows programmer (only an expert VB programmer).  To me, it makes sense to have the parent create the child.  It's just like the listview - window creates a listview, listview creates an item, item creates a subitem - none can really exist without the parent, can they?  Besides, I think I read in another topic that the event handler would be different than IBasic, such that you would have myButton_Click() - or something like that - so it would already need to be a class/object, right?  I dunno... I like my idea, but it doesn't seem to be getting many votes, so I'll keep quiet now.   

Okay, quiet time is over.

In all honesty, I don't foresee control creation to be any type of hangup for anyone.  As long as it's easy to read, and 1 line of code, I think we'll all get used to the syntax.  I do think it should be its own class/object though, then you can do cool things like this...

Code Select Expand


myButton.Move(120,45,40,20);
//or even...
myButton.Left = 120;
myButton.Top = 45;

//or how about...

myButton_OnClick() {
    myButton.Text = "I've been clicked";
}


Okay, I'll be quiet now... let the people who have actually paid for Aurora be heard.

-Thad

[Ionic Wind Support Team]

Generally speaking all windows are created as a single entity, even controls.  It's the parent you specify in the CreateWindow or CreateWindwEx statement (in terms of the API).  So the parent doesn't create the child, the child is created with the parent as a parameter and a style (WS_CHILD).

Controls will have classes, regaurdless of how we create them.  It has enormous usefullness. 

For example you can derive a class from an edit class, and in the derived class subclass the windows control to provide more functionality. Numeric edits, hex entry, etc.  Without having to recreate the wheel each time.

class NumEdit : edit
{
....
int m_nMin, m_nMax;
}

It is something we do in C++ without even thinking about it. 

Paul.

[Parker]

I like the idea of having everything embedded in a class. This is easier to read in my opinion:

Code Select Expand

edit Edit1;
Edit1.Create(...);
...
var = Edit1.GetText();
than this:

Code Select Expand

control(..., 1);
var = GetControltext(win,1);

And once class constructors can take parameters, you can create them in one line:

Code Select Expand

edit Edit1("Text", 0, 0, 100, 20, WS_VISIBLE | WS_CHILD, MyWin, ControlID);

[GWS]

That sounds OK .. 

Graham

[Bruce Peaslee]

That sounds OK ..ÂÃ, 

Graham

Looks good to me, too.

[Ionic Wind Support Team]

Aurora just created it's first button (natively that is)

btn.Create(40,40,80,20,AWS_VISIBLE,10,"Close",w);

In keeping with leaving the power up to the programmer I've left visibility up to your code.  However I do add the WS_CHILD style automatically since it would be unusual to create a control without a parent.

The button class can create buttons, checkboxes or radio buttons by changing the style.

btn.Create(40,40,80,20,AWS_VISIBLE|AWS_CHECKBOX,10,"Close",w);

[Bruce Peaslee]

Looks like an easy syntax. In the next update?

[Ionic Wind Support Team]

Yes.   It will be in the next update.