Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Wed 18 Sep 2019

Perils of PDF 5: Data Confusion



Mon 16 Sep 2019

About that email in Notes



Mon 9 Sep 2019

Perils of PDF 4: Missing and obscured data


December, 2019
SMTWTFS
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

Search the weblog





























Genii Weblog

OpenSesame: Reading/writing properties across multiple entities

Wed 9 May 2007, 11:03 AM



by Ben Langhinrichs
I am facing a design decision which was already resolved long ago for our Midas Rich Text LSX, but I have to decide whether we should make the same decision for OpenSesame.  Let's take the example of a chunk in Midas defined as "Table 1".

Set rtchunk = rtitem.DefineChunk("Table 1")

Now, let's and read and write the FontColor property.  As described in the Help link provided:
When read, this is the color specified in the first text record encountered (presumably the color for this chunk).  When written, this sets the color for all text records in this chunk.
In other words, an attribute such as font color may apply to many elements within the defined chunk, but the general rule for attributes is that when reading those attributes, Midas will stop when it finds the first one and return the attribute for that, even if all the others are different, but when writing those attributes, Midas will apply the attribute to every element found.  Thus, if we started with the following table:
The big brownfox jumped over
the small greenhedge.


and wrote

Print "The font color is "+rtchunk.FontColor

we would read the result

The font color is Blue

but if we added 

rtchunk.FontColor = Red

and saved, the result would be 
The big brownfox jumped over
the small greenhedge.


It should be noted that this general rule applies to attributes of things, such as size, color, etc., but content either follows the example of the Text property, where only the first content is set to the value and all others are blanked out, or it follows the example of the  SectionTitle property, where each section title is replaced.  Unfortunately, it is hard to tell which should be which, and when writing it, I simply used my judgement to determine what people were likely to want to do, and what would leave oddities (such as blank section titles).

So, after that long winded explanation, do I follow the same general rules for OpenSesame?  Does the concept still hold because it is still essentially rich content, or is there a better way?  There is always a different way, such as having a separate property which determines whether the first or all should be overwritten, but I picture that as very confusing for users, or we could go with methods instead of properties to set values, but that might also be confusing.  Any thoughts?

Copyright © 2007 Genii Software Ltd.

What has been said:


581.1. Matt Vargish
(05/09/2007 12:11 PM)

Its an interesting problem. If you don't overwrite the whole chunk, you make an annoyance for the user in that they have to loop through the constituent (child) chunks if they do want it all changed; it makes sense to me that the burden should fall to the user to process the child nodes individually if they need that granularity.

One thing I've thought when writing against such models is that it would be nice to have a convenience method to check on the child elements without having to execute the loop, something like:

if rtchunk.childPropertiesMatch("FontColor", rtchunck.FontColor) then

' code to change the whole block

else

' code to loop each element and make a decision

' or perhaps skip / log / recurse /etc

end if

The method could take additional parameters, for example to narrow the scope of the match (e.g. only check table cells not text fragments).


581.2. Milos Lapis
(05/10/2007 06:42 AM)

I agree with Matt. I would be helpful to find out if there are differecies in attributes on the text fragments inside cells against table cells and then run a different code or apply changes to all cells in a table.