Leaving the Dark Ages with GUI
16 posts
• Page 1 of 2 • 1, 2
Leaving the Dark Ages with GUI
Just looking for opinions and experiences here! I have a couple of different paths forward and I'd like to know what people have done before me.
I'm trying to move GUI stuff out of the dark ages ([]WC) and into the here and now ([]NEW). I'm still planning to use Dyalog's GUI and not winforms. What I'd like to do, as is suggested in the examples, is to create classes that inherit from the Dyalog GUI. I've hit a bit of a hitch converting because:
In the "good old days" everything that was a Dyalog GUI had a name. If I wanted to know what objects a form owned, I could just use []NL.
In the []NEW days, it seems nothing really has a name, although I can mimic a name by assigning the object into a variable. So I can't just ask a form what GUIs it owns with []NL unless, like in the bad old days, I give everything a name, which is a bit of a pain since []NEW won't actually do that and I'll end up using an execute to make it happen.
In the []NEW days, it seems more appropriate to do like VB does and just have each Form maintain a collection (or in Dyalog just a vector) of its children. Although this seems perhaps like the way to go, it seems odd to have to do it since unlike in VB, I actually create the child GUI objects directly INSIDE the form.
Going the VB route also has the downside that if someone goes outside my class structure and creates a child GUI object with []WC, it doesn't just automatically run through all my code the way it used to when everything was done with []NL.
So... do I name everything with goofy names like I used to (guiobj1, guiobj2, etc) even though it seems backwards to do this now? Or should I go with the list that I have the form class maintain?
And, as an aside, doesn't it seem that since I have to create an object inside its parent GUI object, shouldn't I be able to ASK the parent who its children are? (and then I wouldn't have this controversy at all?) Doesn't the Dyalog C code underneath know the answer to that question?
I'm trying to move GUI stuff out of the dark ages ([]WC) and into the here and now ([]NEW). I'm still planning to use Dyalog's GUI and not winforms. What I'd like to do, as is suggested in the examples, is to create classes that inherit from the Dyalog GUI. I've hit a bit of a hitch converting because:
In the "good old days" everything that was a Dyalog GUI had a name. If I wanted to know what objects a form owned, I could just use []NL.
In the []NEW days, it seems nothing really has a name, although I can mimic a name by assigning the object into a variable. So I can't just ask a form what GUIs it owns with []NL unless, like in the bad old days, I give everything a name, which is a bit of a pain since []NEW won't actually do that and I'll end up using an execute to make it happen.
In the []NEW days, it seems more appropriate to do like VB does and just have each Form maintain a collection (or in Dyalog just a vector) of its children. Although this seems perhaps like the way to go, it seems odd to have to do it since unlike in VB, I actually create the child GUI objects directly INSIDE the form.
Going the VB route also has the downside that if someone goes outside my class structure and creates a child GUI object with []WC, it doesn't just automatically run through all my code the way it used to when everything was done with []NL.
So... do I name everything with goofy names like I used to (guiobj1, guiobj2, etc) even though it seems backwards to do this now? Or should I go with the list that I have the form class maintain?
And, as an aside, doesn't it seem that since I have to create an object inside its parent GUI object, shouldn't I be able to ASK the parent who its children are? (and then I wouldn't have this controversy at all?) Doesn't the Dyalog C code underneath know the answer to that question?
- Maria
- Posts: 4
- Joined: Thu Nov 26, 2009 12:33 pm
Re: Leaving the Dark Ages with GUI
Hi Maria,
You ask a number of questions in your post and I'm not sure I understood all of them. I'm relatively new to the GUI stuff, but have opted to go with the "Good []NEW Days." For consistency's sake, I derive a class from every GUI "object" I use including items like Separator for which there is no real benefit in doing so other than consistency.
My Form class is as follows:
Here's a copy of my menu class:
I think you'll get the general idea of how I set up my classes by looking at the code I posted. Let me know if this answers any of your questions and whether you think my approach is sound.
You ask a number of questions in your post and I'm not sure I understood all of them. I'm relatively new to the GUI stuff, but have opted to go with the "Good []NEW Days." For consistency's sake, I derive a class from every GUI "object" I use including items like Separator for which there is no real benefit in doing so other than consistency.
My Form class is as follows:
- Code: Select all
:Class FormClass : 'Form'
:field private MyControls←⍬
∇ FormClass Caption_
:Implements constructor
:Access public
Caption←Caption_
∇
∇ FormClass_
:Implements constructor
:Access public
∇
:property Controls
:access public
∇ r←get
r←MyControls
∇
:endproperty
∇ {r}←AddControl Type
:Access public
Control←⎕NEW Type
MyControls,←Control
r←Control
∇
:EndClass
Here's a copy of my menu class:
- Code: Select all
:Class MenuClass : 'Menu'
:field private MyCallBackObj_
:field private MyMenuItems←⍬
∇ MenuClass(Caption_ CallBackObj_)
:Implements constructor
:Access public
Caption←Caption_
MyCallBackObj←CallBackObj_
∇
∇ MenuClass_
:Implements constructor
:Access public
∇
:property MenuItems
:access public
∇ r←get
r←MyMenuItems
∇
∇ set x
MyMenuItems←x.NewValue
∇
:endproperty
∇ {r}←AddMenuItem(Caption CallBack);MenuItem
:Access public
MenuItem←⎕NEW #.MenuItemClass(Caption CallBack MyCallBackObj)
MyMenuItems,←MenuItem
r←MenuItem
∇
∇ {r}←AddMenu Caption;Menu
:Access public
Menu←⎕NEW #.MenuClass Caption
MyMenuItems,←Menu
r←Menu
∇
∇ {r}←AddSeparator;Separator
:Access public
Separator←⎕NEW #.SeparatorClass
MyMenuItems,←Separator
r←Separator
∇
:EndClass
I think you'll get the general idea of how I set up my classes by looking at the code I posted. Let me know if this answers any of your questions and whether you think my approach is sound.
- Erik.Friis
- Posts: 66
- Joined: Mon Apr 04, 2011 3:16 pm
Re: Leaving the Dark Ages with GUI
Maria wrote:...
I'm trying to move GUI stuff out of the dark ages ([]WC) and into the here and now ([]NEW). I'm still planning to use Dyalog's GUI and not winforms. What I'd like to do, as is suggested in the examples, is to create classes that inherit from the Dyalog GUI. I've hit a bit of a hitch converting because:
...
I'd suggest from my own experience, you could use the Causeway CPro system, that comes with Dyalog.
That enforces a useful separation of data model/calculation engine from the GUI,
it is pure Dyalog and even gives you total freedom at how you write the pure GUI code,
hidden inside the CPro Class modules.
I personally ran always into troubles of some kind, if (too much) inheritance was used
in connection with GUI objects. There was always some or other limitation of the various
GUI frameworks, or by the language (C++/Java), or unforseen incompatiblities of a derived
class, after a change to a base class. I keep inheritance to an absolute minimum and
prefer to fork and modify the GUI code.
Just my two cents...
JoHo
Last edited by JoHo on Mon Jun 06, 2011 9:32 pm, edited 1 time in total.
-
JoHo - Posts: 37
- Joined: Sat Nov 28, 2009 12:51 pm
- Location: Austria, EU
Re: Leaving the Dark Ages with GUI
Hi JoHo,
I understand that it's a screen design system that was written before Dyalog introduced classes and as such it is not truly OO. I think this will return Maria to the "bad old days" from which she wants to emerge. I'm sure it's a good system, but I hope Dyalog modernizes it to use real classes and OO.
My vote at this point would be for her to create cover classes for each of the GUI objects she wishes to use. The physical sizing and layout of the controls is a bit challenging as this sort of stuff is much better done visually a la VB.
Regards, Erik
I understand that it's a screen design system that was written before Dyalog introduced classes and as such it is not truly OO. I think this will return Maria to the "bad old days" from which she wants to emerge. I'm sure it's a good system, but I hope Dyalog modernizes it to use real classes and OO.
My vote at this point would be for her to create cover classes for each of the GUI objects she wishes to use. The physical sizing and layout of the controls is a bit challenging as this sort of stuff is much better done visually a la VB.
Regards, Erik
Last edited by Erik.Friis on Tue Jun 07, 2011 4:22 pm, edited 2 times in total.
- Erik.Friis
- Posts: 66
- Joined: Mon Apr 04, 2011 3:16 pm
Re: Leaving the Dark Ages with GUI
Have you considered the next jump to WPF? (Windows Presentation Foundation)
-
MikeHughes - Posts: 86
- Joined: Thu Nov 26, 2009 9:03 am
- Location: Market Harborough, Leicestershire, UK
Re: Leaving the Dark Ages with GUI
Hi Maria,
We do have an RFE to improve metadata functions such as ⎕NL. I will log an RFE for something to ask the parent who its children are in the context of the ⎕NEW GUI world. We currently have a Windows Child Names system function (⎕WN) which only works with objects created by ⎕WC.
The C code does know the answer to the question...
Regards,
Vince
Maria wrote:In the "good old days" everything that was a Dyalog GUI had a name. If I wanted to know what objects a form owned, I could just use []NL.
...
And, as an aside, doesn't it seem that since I have to create an object inside its parent GUI object, shouldn't I be able to ASK the parent who its children are? (and then I wouldn't have this controversy at all?) Doesn't the Dyalog C code underneath know the answer to that question?
We do have an RFE to improve metadata functions such as ⎕NL. I will log an RFE for something to ask the parent who its children are in the context of the ⎕NEW GUI world. We currently have a Windows Child Names system function (⎕WN) which only works with objects created by ⎕WC.
The C code does know the answer to the question...
Regards,
Vince
- Vince|Dyalog
- Posts: 432
- Joined: Wed Oct 01, 2008 9:39 am
Re: Leaving the Dark Ages with GUI
Being something of a simpleton I don't really understand the original post, but for years I've been relying on stuff like...
f←⎕new 'Form' ''
f.l←f.⎕new 'Label' ''
f.⎕nl 9
l
which I've found far preferable to all the ⎕WC/G/S stuff. The only fly in that ointment being that some (obscure?) things seem to still need ⎕WC.
Something I found useful, particularly from the viewpoint of conserving energy, was defining my own GUI objects as simplified simple-to-use classes - I described this in "OO For The Elderly" at Dyalog's 2008 event, the words should be on Dyalog's website, but are also here...
http://88.97.16.226/apl/APL/Papers/OOElderly.html
Mike's suggestion of WPF is also valid, and may open up a whole new world of wonder and misery.
f←⎕new 'Form' ''
f.l←f.⎕new 'Label' ''
f.⎕nl 9
l
which I've found far preferable to all the ⎕WC/G/S stuff. The only fly in that ointment being that some (obscure?) things seem to still need ⎕WC.
Something I found useful, particularly from the viewpoint of conserving energy, was defining my own GUI objects as simplified simple-to-use classes - I described this in "OO For The Elderly" at Dyalog's 2008 event, the words should be on Dyalog's website, but are also here...
http://88.97.16.226/apl/APL/Papers/OOElderly.html
Mike's suggestion of WPF is also valid, and may open up a whole new world of wonder and misery.
Visit http://apl.dickbowman.com to read more from Dick Bowman
-
Dick Bowman - Posts: 235
- Joined: Thu Jun 18, 2009 4:55 pm
Re: Leaving the Dark Ages with GUI
Vince|Dyalog wrote:The C code does know the answer to the question...
If so, I think we should make this a priority for v13.1.
-
Morten|Dyalog - Posts: 458
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Leaving the Dark Ages with GUI
I have an even more basic question. What is the difference between
'F' []WC 'FORM'
and
[]NEW 'FORM' ''
My understanding was that the latter tapped into Windows Forms of the .NET but apparently that is not so because the latter works without defining a []USING (unless []USING is always defaulted so it can find the appropriate assembly for WinForms)
Why is []WC old and []NEW the new way? What advantages do you get by using []NEW?
As an aside, is more choice always a good thing???
Neeraj Gupta
'F' []WC 'FORM'
and
[]NEW 'FORM' ''
My understanding was that the latter tapped into Windows Forms of the .NET but apparently that is not so because the latter works without defining a []USING (unless []USING is always defaulted so it can find the appropriate assembly for WinForms)
Why is []WC old and []NEW the new way? What advantages do you get by using []NEW?
As an aside, is more choice always a good thing???
Neeraj Gupta
- neeraj
- Posts: 82
- Joined: Wed Dec 02, 2009 12:10 am
- Location: Ithaca, NY, USA
Re: Leaving the Dark Ages with GUI
neeraj wrote:Why is ⎕WC old and ⎕NEW the new way? What advantages do you get by using ⎕NEW? As an aside, is more choice always a good thing???
- ⎕NEW is the new way because it was introduced with version 11.0 (2006), while ⎕WC dates back to version 6.3 (I think). Thus, ⎕WC is approximately 15 years older, and pre-dates not only classes but also namespaces.
- The advantage of using ⎕NEW is that it fully recognises the built-in GUI objects as the classes that they obviously are. For example, you can derive classes from them, see e.g.
http://help.dyalog.com/13.0/html/writing%20classes%20based%20on%20the%20dyalog%20gui.htm - More choice is not necessarily better, but it would be quite strange NOT to allow GUI classes to be instantiated using ⎕NEW.
neeraj wrote:What is the difference between
'F' ⎕WC 'FORM'
and
F←⎕NEW 'FORM' ''
In fact, there *is* a subtle difference, which you will notice if you display the two forms. The former displays as '#.F', and the latter as '#.[Form]'. This is because the old function creates a form which “knows it’s own name”, while the new objects are “unnamed”. This only matters if you write code which uses names (which is now also considered an “old style”) rather than refs (“new style”).
-
Morten|Dyalog - Posts: 458
- Joined: Tue Sep 09, 2008 3:52 pm
16 posts
• Page 1 of 2 • 1, 2
Return to Object Oriented Programming
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group