Re: Java compatibility issues (WAS: MF having issues?)

Pete Dashwood wrote:


Let's take it out of sequence for a minute. I wrote...

>>Obviously with of Values (text) you could implement a SEARCH (I think,
>>never having tried it).

Thought about that. There's no bloody way I could do that with the Procedural SEARCH syntax against an OO Collection. So was going to ask you how the hell you do it ! Glad we've cleared that one up, and you latched on to what I'm a actually doing.


Yes, I understand what you are saying. You are talking about using the SEARCH to search a collection. You can't do that (in any OO implementation, as far as I know. You could if you loaded the collection into a table, but that kind of defeats the object of a collection, and COBOL cannot support dynamic tables anyway (without help from oputside sources and environments).

Some day when King Arthur returns to this mortal coil, somebody *might* implement J4's Dynamic Working-Storage Tables.

Diiferent contexts of the word SEARCH. It's clear now.

That is interesting. I have never come across a collection object that required capacity. The whole point of the collection is that it grows dynamically and HAS no capacity; at least in the environments in which I use them.

I think Will mentioned it in his book, (yours now being dog-eared or lost), but it is a feature M/F picked up from Smalltalk when designing Collections. You have the ability to 'grow' automatically as you write above. However an example from Adele Goldberg in her 'Smalltalk 80'. Small ferry boat shunting cars across a harbour, (perhaps Seattle). The boat has a max CAPACITY of 6 vehicles. So if you want to automate it you can load each vehicle automatically giving you SIZE and check CAPACITY so that you don't push car #1 off the front as you go to load car # 7 !

Probably a more effective usage, rather than just growing, element by element, which means you are repetitively going though an 'expansion' procedure. Knowing that you have a list which could contain 100 elements, you can start by making the collection have a CAPACITY of 100. You only load 50 elements. invoke myCollection "size" returning size. If SIZE is less than CAPACITY - stupid method-name coming up - invoke MyCollection "growTo" using mySize - "growTo" meaning increase or decrease - adjusting your memory requirements.

Yes, I understand that, but the colllection classes I use in FJ and VB simply don't require capacity. (Neither should they, in my opinion.)

Nor do they in M/F - just a feature you can use if you want to - I don't.

So, can you explain why you differentiate between a sorted collection and an ordered one?

I think we've cleared that one up too. Subsequently remembered you don't have a Sorted Collection class in F/J. Surprise, surprise not did J4 on first run around with Collections as the author was referencing F/J concepts. Same author in private e-mail queried the validity of Dictionary/Maps - in all innocence I posted my rely to him via softwaresimple.com., thinking others of you could comment. He didn't like that - back came a snotty reply and we haven't communicated since. (Politics, bloody politics !).

J4 only added it as a result of my bitching. It was Karl Kistler (Fujitsu-Siemens) who gave me the heads-up it had been added.


Independently, unknowingly, I arrived at the same design pattern using a Dialog Template Class. So as I pass parameters(properties) for the control to the Template I 'add' to two Ordered Collections, (no positioning by index, it's the next increment of the index). The first collection holds the 'displayable object' and the second, together with other information, the literal for the Method-name to be returned to after receiving a Windows Event.

I can see how that would work, but it seems very complex, and requires 2 collections where 1 would surely do. I would have the control as a single object.

So WOULD I ! M/F have support classes to create various collections but never figured out how you could do it so that one element could contain both the displayable object and the text for the method-name. Perhaps a two level collection - but couldn't figure it ? So while I consider it clumsy, it works.

Incidentally when defining dictionaries in M/F they can be expressed as follows :-

Key Data
---- ----
Object Object
Object Text
Text Object
Text Text

Given that you have a Primekey/DB-ID of 12345 and name Joe Blow each can be the Key or Data. With those options above you have to specify Dictionary structures - that's what I would have liked to have done rather than those two Collections I have above. (I wouldn't mind betting Robert Wagner could have figured this one for me).

The collection for the dropdown or list box could be a text file (it
doesn't HAVE to be a collection), which could be maintained separately from the control and even built dynamically by other code, before the control is displayed. The control is "pointed" at the text file (or collection) through a control property. When someone clicks on the dropdown list I simply get the string they clicked on. (There are several ways I can do this using properties of the control). The string returned contains the Method which handles that selection, but this part of the string is not displayed. (The control has properties that determine how much of the string gets shown, and you simply don't add a horizontal scroll to the control).

We aren't poles apart on this one - briefly I'll try and describe :-

----------
DBI Main
----------

------------- ----------- ------------------
EditCustomers CustomerDBI COBOLFile/SQLtable
------------- ----------- ------------------

----------- ------------------
Customer Tabbed Dialog
DialogParams
------------ ------------------

EditCustomers is selected from the Master Menu and is the Business class for this sub-module. I have set up the info from Dialog Editor (not Dialog System) as a set of parameters/properties for each Control. These parameters are passed to TabbedDialog to create an instance which is CustomerDialog - don't need any more, so I can destroy/finalize CusomerDialogParams.

DBI - terminology I picked up from Will. DBI = Database Interface. Not mentioned in his book, but the white paper he sent me with his First Edition.

COBOL File/SQL Table - doesn't matter I keep them vanilla-flavoured so that I can access as necessary - directly from an invoke from Customer Edit or via the CustomerDBI.

Step 1 - all specific DBIs inherit from DBIMain.

Step 2 - Create a collection/dictionary - from EditCustomers invoke CustomerDBI using parameters - Step 3 below

Step 3 - rather than remember the syntax for creating collections I pass parameters to DBI Main to create any collection/dictionary. The parameters also include the positioning within an element for the columns, even though as a standard I allow three sequences identified by Level 88's - ByName (default), ByKey, ByOther if relevant.

Step 4 - Now I want to create the collection (independently of the GUI procedure). CustomerDBI now invokes "readNext" against a COBOL file or CURSOR SELECT for SQL. The object reference and method-name within Customer DBI are passed to File/Table as appropriate - in the case of SQL CURSOR - until reaching 'No more Rows' the Table class sends the Table row data, as required, back to CustomerDBI. The latter formats the text, the latter part of Step 3 - it now uses super DBIMain to add to the appropriate collection.

Step 5 - when the collection is complete it is now returned to CustomersEdit - which knowing the appropriate Field Number associated with a ListBox or Droplist now invokes the instance of CustomerDialog :

invoke os-CustomerDialog "setContents" using Field Number

(which is the INDEX position) of the appropriate displayable control in that First DisplayableObjectCollectioin above.

Step 6 - just like you I'm using the selection event to get the index position for the Listbox or Droplist which is returned to Controller - CustomersEdit. That now invokes CustomerDBI, by-passing it and checking (super) DBIMain. I have a whole daffy of methods in DBIMain which 'translate' or 'search' as necessary. The instance relates to only one original 'list' and I have the column positioning in the element to help me track.

Note - the empahsis above is to make screening a dumb terminal - no decision making other than Windows events. Creation/changing of collections is done entirely outside of GUI-ing. Back to your Compuserve mention of Three-Tier Systems - if I've misinterpreted - then it's your fault :-)

So why not have one collection?
Got your answer above on that one.


Yes, I use a special Fujitsu Collection for TreeViews called a Node. The node object has properties and methids that allow icons and subclasses to be added to a Tree View. It is a very useful control. (Anyone interested could have a look at a paper I wrote some time back on this, that has been picked up and is posted on several web sites - so much for copyright on the web...I intended it to be helpful so I really don't mind it being disseminated...Here is one of the links to it: http://ar.geocities.com/pcobolar/tutorial1/tvtutorial.doc)

That routine I described above is also used identically to access Files/Tables to create Treeviews - my test example had three levels :-

Level 0 = "Cheese"
Level 1 = Continent
Level 2 = Country
Level 3 = 12345 Cheddar Cheese.


This is good stuff but it is simply re-inventing the wheel. There are any number of drop down combo box controls that already have all of this functionality in them. I think it is admirable to build your own solutions, Jimmy, but I wouldn't have the time or inclination to do this when I have components that already do it.

I sincerely hope you reuse this code (without duplicating it... :-)) each time you need a combo box selection...

Well hopefully above demonstrates that I am R-E-U-S-I-N-G. The code contained in the individual DBIs is minimal - the donkey work being done in DBIMain for ALL lists, whether displayable or not.

Checking Keys :

I sort of get the feeling you half mentioned it above. Retrieving the COBOL Primekey/or SQL ID. I asked in the M/F Forum, not really receiving a 'positive' which led me to,'This is the way to go'. Simon jumped in and suggested a parallel collection containing keys. I checked the Microsoft site - certainly getting the feeling that they were recommending the same approach. Just like you observed above, "Why two collections ?" - to which the answer is I wouldn't if I could have figured it out :-).

I have my PrimeKey/SQL-ID built into my list elements. And if I use the feature display ByKey - that's the sequencing I get. In the case of Droplists I don't want to confuse users with mnemonics when selecting 'Canada' - tip from Ken Mullins, make the droplist Mono spaced font which stretches it out, exceeding the width of your droplist, so that the code is hidden to the right.

Jimmy
.

Relevant Pages

  • Re: Java compatibility issues (WAS: MF having issues?)
    ... control to the Template I 'add' to two Ordered Collections, ... EditCustomers CustomerDBI COBOLFile/SQLtable ... DBI - terminology I picked up from Will. ... that First DisplayableObjectCollectioin above. ...
    (comp.lang.cobol)
  • Re: NullReferenceException in UnsafeNativeMethods.PeekMessage and multithreading concepts in general
    ... this Invoke method but it haven't dawned on me till now. ... > This comes from Windows OS and because .NET controls use internaly Windows ... To handle those problems Control ... >> reason, ApplicationContext context) ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: DataBinding and updating on non UI thread
    ... explicitly referencing a control or form. ... > just have the databinding stack figure out that it needs to call Invoke ... > Mark. ... >>> Here is my datasource, a person class that raises the PropertyChanged ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: DataBinding and updating on non UI thread
    ... Mark ... > usually the programmer of the control to make sure that any bound data ... > is changing the data source should be aware of this, ... >> just have the databinding stack figure out that it needs to call Invoke ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Populate an ImageList from another thread
    ... Invoke(), but working around a deadlocking design bug isn't one of them. ... In situations where there _is_ some kind of potential deadlock problem, ... those updates all come at once, after the background thread is done. ... BackGroundWorker user control. ...
    (microsoft.public.dotnet.languages.csharp)