[Mischa]

Hi Andreas,

I’ve put a sample library together, actually all classes necessary to demonstrate the conversion problem are dragged from my library into sample.lbs. It seems, that converting less classes has an effect, because now not all problems I’ve reported here come up for whatever reason.

sample.lbs is a OS 10.1 library. Please run it with 10.1 first just to check that it works (Windows 10, have not tested on a Mac). After opening the library, please open folder Persons and open window PersonsSQL. Hit pane ‘Angehörige’ and enter ‘klement’ into the search field. The window now should look like in the upper half of the image below.

Now open the library with Studio 11 (latest version) and do the same. As you should see, the window title is missing, also the persons in the search list have no label anymore.

The window title is generated in the $redraw method of PersonsSQL with

Calculate $cwind.$title as iRow.$label(1)

where iRow is a subtype of the table class tClients.

The labels of the persons in the tree list are generated in the same way in the window class widTreeList with

Do iTreeRef.$setrootnode(iRootRow.$iconid,iRootRow.$label(1),iRootRow.UID,iRootRow.$dataclass,iRootRow,kTrue)

You can download the sample here, it includes a sample SQLite db, please put it into the same folder as the library.

http://www.microartwork.com/Products/sample.zip

best greetings and thanks
Mischa

microartwork.com

500 Internal Server Error

500 Internal Server Error

[Mischa]

Hi Andreas,

thank you for your reply.

I am not sure what you are trying to achieve using the $prepare of a row variable when using a schema

Seems that it is required to prepare the statement object before you launch an SQL statement?

The problem however is, that the subtype of the row variable definition is ignored, regardless whether you use a schema or table class – please see picture one.

Another strange example is that a parameter, although populated correct, is not trapped in the switch statement – please see picture two. pType is an integer 255.

From my perspective, there is a conversion problem with $label and/or the new method editor. When a new property is introduced, it must not break the existing code, when a developer has used the same property name before. That should be a no go for every development platform.

thanks
Mischa

[Mischa]

Hi Andreas,

thank you for your reply. It appears to be a conversion problem. When I copy the method lines and then completely delete the $label method in the table class, recreate the method $label again and paste the code into it, all local and parameter variables are not resolved by the code editor (they appear as black text) and must be defined manually again. After this, $label works as expected again.

I have another case, where a local variable is defined as schema class subtype in the definition table, but myRow.$statementobject.$prepare() causes an unknown property error, although the row is shown as not empty and its definition matches the schema class.

I have to insert a Do myRow.$definefromsqlclass(‘sSchema’) at the start of the method, then it works.

So it seems that local variables are not always converted correct, and it’s very hard to see, when and why the conversion fails, since I’m doing a subtype definition of local rows and lists all over the library and they appear to work without a problem as far as I have tested yet.

So what I can offer is to send the whole library since the occurrence of the problem is not predictable.

best greetings and thanks

Mischa

[Mischa]

Hi Andreas,

thank you for your reply. This is the code behind the complex grids:

Calculate mLine as iAddrList.$line ## preserve selected line
Do iAddrList.$sendall(mIconRef.[$sendallref.$line].$text.$assign(style(kEscBmp,iAddrList.$iconid+k32x32)))
Do iAddrList.$sendall(mLabelRef.[$sendallref.$line].$text.$assign(iAddrList.$label(2)))
Calculate iAddrList.$line as mLine

So nothing special mIconRef and mLabelRef refer to the two bobjs text fields in the complex grid. iAddrList is the list that holds the data – addresses in this case. Its definition is tAddresses, the table class. The code works for the icon, but not (always) for the text, that is calculated in the custom $label of the table class property. Doing exactly the same in a remote form works, as you can see in the attached image. Unfortunately, the remote form has limitations like not being able to hi-lite the selected line or displaying wanted line breaks in the text, rendering complex grids widely unusable for remote forms.

The code for $label in the table classes looks pretty unspectacular:

Switch pType

Case 1 ## one liner
Calculate mLabel as con($cinst.Street,pick($cinst.Street>'','',', '),$cinst.PCode,' ',$cinst.City,', ',cCountryObj.$countryfullname($cinst.Country)

Case 2 ## two liner
Calculate mLabel as con($cinst.Street,pick($cinst.Street>'','',', '),chr(13),cCountryObj.$countrycept($cinst.Country),'-',$cinst.PCode,' ',$cinst.City)

Default ## three liner
Calculate mLabel as con($cinst.Street,pick($cinst.Street>'','',chr(13)),$cinst.PCode,' ',$cinst.City,chr(13),cCountryObj.$countryfullname($cinst.Country))

End Switch
Quit method mLabel

The code in the $redraw method of the window class simply is

Calculate $cinst.$title as iRow.$label

Let me emphasize that everything used to work fine in OS versions prior to 10 (images 2 and 3 show the examples in OS 8.1), and also in OS 11 it does not work anymore.

My primary suspects are the new method editor and/or the conversion that break the code.

thanks
Mischa

[Mischa]

Hi Andreas,

If the subform field width is smaller than 768 it will take the next smaller layout breakpoint

Now I got it. So when I provide only one layout breakpoint, it will be always used?

Calculate iTest as $cinst.$container().[iDataName]

This is really lovely! Thanks a lot, no more hassle with dynamic methods 😉

Calculate iDataName as lClassRef.$objs.[$cinst.$field].$dataname

It seems that [$cinst.$field] resolves to kTrue, so I’m always getting the $dataname of the first object in the container form – but [$cinst.$field.$name()] does the trick.

Still need to do some tests if the $class approach (either dynamic or your solution) also works, when the subform field is buried within containers like panes or complex grids.

best greetings and thanks a lot!

Mischa

[Mischa]

Hi Andreas,

So for example if you have a 320 and a 768 layout breakpoint then the 320 is shown until the browser reaches 768

I guess, here on my desktop the browser should be way beyond 320 pixel (even when they are logical)? However, since the country picker should look like a standard entry field, everything is done with floating attributes, so actually no layout breakpoint is needed.

Regarding the automated creation of a method it actually has two sides
of a coin. I would assume that this code is harder to maintain

I general you’re absolutely right, and I normally would not work with dynamical methods. Also, they mess with the new method editor (since $OS 10), breakpoints do not work anymore.

But here we have two totally simple methods only, and they stay the same for every subform, where this technique is used (that’s every subform in my case 😉).

$getval -> Quit method MyVar
$setval -> Calculate MyVar as pValue

The obvious problem here is that the name of MyVar is unknown to the subform instance, this is why I was so keen to utilize the $dataname property of the subform field. It’s the logical place to assign a variable to a field – you do it in every other field type, too.

So I assign the variable MyVar to the $dataname of the subform field, and add another line to the generated methods and do it like that:

Calculate mDataname as $cclass.$objs.[$cinst.$cfield.$name()].$dataname 
Quit method [mDataname]

Regarding the click event behind the label field please check if the label is active and enabled

<div>ahhh – I missed the active flag. Maybe it should be placed into the Visibility & State section, too.</div><div>

Thanks a lot, this was great help!
Mischa

</div>

[Mischa]

Hi Andreas,

*ggg* found out that the $dataname property actually is available within a client method – kinda makes sense 😉

best greetings
Mischa

[Mischa]

Thanks Andreas!

[Mischa]

ooops the first line in the While loop should read

Calculate mPath as con(mDataname,'.$objs.',mPath)

😉

[Mischa]

Hi Andreas,

as already suspected, the $class approach does not work, when the subform field is within another container like a tab pane.

Also, there appears to be no easy way to drill down the object path from within the subform instance, since the instance has a flat hierarchy. I ended up with creating a dynamic method behind the subform field:

Calculate mDataname as $cfield.$container().$name
While mDataname<>''
    Calculate mPath as con(mPath,mDataname,'.$objs.')
    Calculate mDataname as $cinst.$objs.[mDataname].$container().$name
End While

Calculate mPath as con(mPath,$cfield().$name)
Calculate mDataname as $cclass.$objs.[mPath].$dataname
Quit method mDataname

This works, however I really would love to see the $dataname property being available also in subform instances – this would make it much easier and more elegant. May I suggest this enhancement request?

thanks

Mischa

[Mischa]

Hi Andreas,

ahhh – this was it, thanks a lot! Since I’m a total newbie to jsClient – may I ask, why Omnis chooses the 320 over the 768 layout in this case? The subform field has a width of 422, so it should be well over the 320 breakpoint.

And another difficulty I run into – the label field (the field that contains the country flag and name) does not react when it’s clicked, although it is enabled and $events is set to evClick.

The $getval and $setval functions of the subform field are created dynamically from within the $construct of the subform – this works nice, the only problem was to get the $dataname, where the values are coming from and written to – it’s nowhere in the subform instance (why?), but looking into $cclass was the solution 😉

Thanks a lot

Mischa

[Mischa]

Hi Andreas,

thanks a lot for your reply and please excuse my late answer – the $field() property was exactly, what I was looking for, and from there on I did a lot of experiments to utilize the $dataname property of the subform field. Seems that Omnis simply forgot about it, but I finally succeeded with a lot of tricks.

While functionally it now works as intended, the GUI is a mess – please look at the picture attached.

On top you see the design of the subform in Omnis, and below the result. At the bottom you see, how it should look like.

thanks a lot

Mischa

nat.png 34 KB Image File - Click to view

Options

• Copy Download Link

[Mischa]

Hi Andreas,

thank you very much for your reply and your demo – where I’m still trying to get my head around 😉

You can take subforms as separate instances and thus they ought to be and work independently.

Not sure if I understand this correct – so the subform is not part of the main form as subwindow is in the fat client?

Do $cinst.$load($cinst.$container().$getID())

What I don’t like with this approach (when I understand it correct) is, that the subform needs to know about its main form, while the subwindow inherently knows about the methods behind the subwindow object, regardless how the main window is structured and how deep the subwindow object is buried in panes, groups or other subwindows.

Maybe it’s easier to show what I want to achieve:

Ok, seems that the forum software cannot display pictures as inline graphics, so please refer to the attached picture.

I designed a country picker, because this is something you come across all the time, often within the same window/form, where you need to pick a nationality for a person, and in another stage, a home address.

In the fat client, I can simply drag the country picker from the component store into the window and assign a variable to $dataname, e.g. iClient.Nationality – that’s all I need to make it work. The subwindow automatically adopts the style of the window – a property I have not discovered for subforms yet (?) – and the main window does not need to know anything about the country picker, it just provides the field containing the country code, that is filled, altered and displayed in the subwindow. I can add the country picker es many times as I want into the main window – providing different datanames is all it takes to keep them apart – no separate callbacks/returns for each picker in the main window.

However, I’m be bit lost how to achieve the same thing with subforms?

thank you!

Mischa