Leaving the Dark Ages with GUI

Writing and using Classes in Dyalog APL

Leaving the Dark Ages with GUI

Postby Maria on Mon Jun 06, 2011 2:17 pm

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?
Maria
 
Posts: 4
Joined: Thu Nov 26, 2009 12:33 pm

Re: Leaving the Dark Ages with GUI

Postby Erik.Friis on Mon Jun 06, 2011 3:44 pm

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:

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

Postby JoHo on Mon Jun 06, 2011 4:27 pm

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.
User avatar
JoHo
 
Posts: 37
Joined: Sat Nov 28, 2009 12:51 pm
Location: Austria, EU

Re: Leaving the Dark Ages with GUI

Postby Erik.Friis on Mon Jun 06, 2011 6:55 pm

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
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

Postby MikeHughes on Tue Jun 07, 2011 8:43 am

Have you considered the next jump to WPF? (Windows Presentation Foundation)
User avatar
MikeHughes
 
Posts: 86
Joined: Thu Nov 26, 2009 9:03 am
Location: Market Harborough, Leicestershire, UK

Re: Leaving the Dark Ages with GUI

Postby Vince|Dyalog on Tue Jun 07, 2011 10:41 am

Hi Maria,

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

Postby Dick Bowman on Tue Jun 07, 2011 10:58 am

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.
Visit http://apl.dickbowman.com to read more from Dick Bowman
User avatar
Dick Bowman
 
Posts: 235
Joined: Thu Jun 18, 2009 4:55 pm

Re: Leaving the Dark Ages with GUI

Postby Morten|Dyalog on Tue Jun 07, 2011 10:58 am

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.
User avatar
Morten|Dyalog
 
Posts: 458
Joined: Tue Sep 09, 2008 3:52 pm

Re: Leaving the Dark Ages with GUI

Postby neeraj on Tue Jun 07, 2011 1:50 pm

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
neeraj
 
Posts: 82
Joined: Wed Dec 02, 2009 12:10 am
Location: Ithaca, NY, USA

Re: Leaving the Dark Ages with GUI

Postby Morten|Dyalog on Wed Jun 08, 2011 12:40 am

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???

  1. ⎕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.
  2. 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
  3. More choice is not necessarily better, but it would be quite strange NOT to allow GUI classes to be instantiated using ⎕NEW.
Some people feel that one should convert to using ⎕NEW for GUI, to be "modern" and in-line with the more general OO features. Personally, I still find that the old style is more readable and leads to shorter code. Old habits die hard.
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”).
User avatar
Morten|Dyalog
 
Posts: 458
Joined: Tue Sep 09, 2008 3:52 pm

Next

Return to Object Oriented Programming

Who is online

Users browsing this forum: No registered users and 1 guest