Oberon Community Platform Forum
December 12, 2019, 08:44:41 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: General Purpose Multiple Instance Handler Module - Updated 3.0  (Read 11792 times)
R.Auge
Newbie
*
Posts: 9


« on: August 26, 2010, 09:22:27 PM »

I've been reading documentation about and using A2/Active Oberon (via WinAOS) for the better part of a week now and I'd like to share my massive enthusiasm about the language and operating environment.  I think both have huge potential and I would really like to contribute to any progress of the platform.

That being said, I thought I would post my first Active Oberon/A2 project for general consumption and critique.

It's a general purpose multiple instance handler module for objects.  It allows any module to easily be extended to support multiple instances of objects.  The intention was to create a uniform way of dealing with GUI elements to prevent orphan windows, but it is general enough that it can be used to enforce the correct termination of any objects from any modules that uses the instance handler system.

I wrote it as a learning exercise to familiarise myself with Active Oberon and the A2 environment.  If anyone finds it useful feel free to have at it.

P.S. (I Had originally posted this in the AOS forum by mistake, so I have moved the post here.)

P.P.S (I have updated the MultiInstance module slightly with a couple of methods I felt would be useful, and repackaged it with all of the examples I have created so far.  The new archive is now attached. )
« Last Edit: August 28, 2010, 03:09:07 AM by R.Auge » Logged
R.Auge
Newbie
*
Posts: 9


« Reply #1 on: August 28, 2010, 03:10:27 AM »

Yet another update.  I believe this will be the final one as I have the module working exactly the way I would like it, so any more changes will be minor. 

* MultiInstance-3.0.zip (9.06 KB - downloaded 263 times.)
Logged
BohdanT
Sr. Member
****
Posts: 271


Life is difficult, but fortunately is short!


WWW
« Reply #2 on: September 01, 2010, 05:23:42 PM »

I do not understand the meaning  Roll Eyes
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #3 on: September 02, 2010, 08:11:36 AM »

I'm actually didn't understand too.
Would you please, describe for what task this approach may be useful.
The A2 GUI patterns shows a technique of using linked list of windows. Do you simply offer to use double linked list of windows?
Logged
R.Auge
Newbie
*
Posts: 9


« Reply #4 on: September 05, 2010, 06:03:05 AM »

The purpose is: to eliminate the direct access of global module variables and procedures from within object methods; to allow a module to have full control over the life and death of any object spawned by it, regardless of what module that object was defined in; to allow the control of any object using a single interface, regardless of the object type; to allow library modules to define objects that can have multiple instances created without the library module being required to keep track of those instances; to allow the passing of ownership of an object instance from one module to another, without the receiving module having to know anything about the object; to allow any object to be easily extended to multiple instance handling regardless of the original use of the object; and to do all of this with a single elegant interface.

The internals of how the instance handler maintains the list are irrelevant, they can be changed in any number of ways so long as the functionality remains the same -- I have in fact created a different version of the the same module that uses an array structure to maintain the list of object instances.

To be honest, the method of defining a window object that increments and decrements a global window instance counter I just really didn't like. I found it very -- limiting.  So I wrote my own method of handling multiple instances, the use of which is not just limited to window objects.

If anyone finds it useful, yay.  If not, whatever.
« Last Edit: September 05, 2010, 06:12:00 AM by R.Auge » Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #5 on: September 06, 2010, 12:50:38 AM »

A minor comment on Oberon programming style:

        IF NIL # Node THEN RETURN TRUE; ELSE RETURN FALSE; END               

Semicolons in Oberon are used as statement separators not statement terminators. The semicolons as used above above are redundant null statements and appear awkward.

        IF NIL # Node THEN RETURN TRUE ELSE RETURN FALSE END       

However, what you would normally see in an Oberon program is simply:

        RETURN NIL # NODE         
Logged

Chris Burrows
Astrobe v7.0 (Feb 2019): Oberon for ARM Cortex-M3, M4 and M7 Microcontrollers
http://www.astrobe.com
R.Auge
Newbie
*
Posts: 9


« Reply #6 on: September 06, 2010, 01:00:30 AM »

The only reason I included the semicolons was I found the second option you represented hard to read -- you'll notice that everywhere else they are used properly.  But the third option you provided is by far the most superior.  Thanks for the input.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!