Leaving the Dark Ages with GUI

[Maria]

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?

[Erik.Friis]

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.

[JoHo]

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

[Erik.Friis]

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

[MikeHughes]

Have you considered the next jump to WPF? (Windows Presentation Foundation)

[Vince|Dyalog]

Hi Maria,

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

[Dick Bowman]

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.

[Morten|Dyalog]

The C code does know the answer to the question...

If so, I think we should make this a priority for v13.1.

[neeraj]

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

[Morten|Dyalog]

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.

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”).