Tab in Reminder Data

Wed Apr 2 08:48:11 PDT 2008

This issue is inherently part of the Panorama paradigm. The only  
practical way to store and retrieve every possible character (any  
binary combination) is to use a logical format where the beginning  
and length (or end location) of each piece of data is recorded.  
Object oriented systems do exactly that, in your computers memory,  
but even they take some shortcuts. For example, in C (and its object  
derivatives) a string is terminated by a null character. This is done  
for performance purposes and ease of implementation. So a C string,  
IN MEMORY, is managed like this:

Pointer to start location of string: MemoryAddressA
MemoryAddressA:  I am a series of binary data that will be  
interpreted as a string sitting in memory[NULL CHARACTER]

So when you compile in C, the standard library that retrieves a  
string uses the pointer to find the memory location, and reads  
forward in memory until it hits [NULL CHARACTER], where it then knows  
it is at the end of the data. In most systems the MAXIMUM string  
length is also known before hand, and if the string does not fill up  
the entire data length, the rest is wasted memory.

Anyway, there are variations, but that suffices as an example.

So Jim has written kind of a hybrid system, which has some inherent  
flaws (as all systems do), but which allows us as programmers to take  
advantage of a high level programming environment. Those advantages  
are directly related to the flaws. I am not privy to the internals,  
but based upon some statements and having used the system, I can  
guess at the internal logic.

The most important point is that internally, however its set up,  
accessing fields is done by a start location and a length (Although  
apparently the start location of a field is not known without  
examining previous fields in the record, based on statements on Find  
performance). Else-wise, it would be very difficult to support binary  
data. However, and HERE IS THE POINT (which I took forever to get  
to): Many of the programming functions and graphical objects which  
we, as Panorama programmers, have access to, use delimiters to  
manipulate the data. This is great from a lot of perspectives, but is  
does mean that, when writing applications, you need to take explicit  
control and prevent your delimiters from randomly appearing in data.

It also means that when when attempting to write the sort of  
functionality you are shooting for, you are going to have to use a  
slow process, such as creating a file format (whether in memory or on  
disk) which utilizes offsets to access data, or creating a list of  
variables dynamically, with loadvariables or execute or something.  
Personally, I don't think its worth the effort to implement this more  
complex method in the case you mention. Most likely its only worth it  
if you have binary stuff you need to process.

Having said all that, here are some possibilities.

If Reminders is the only Binary data you are likely to run across,  
and you have full control of the data used in other fields, Reminders  
may use a limited set of internal Binary possibilities, depending on  
how it was written. If Jim made those public, or listed one or two  
which he knows will not appear in the internal data, then you could  
make sure that you were not replacing something which exists (say,  
when you replace, Tab with Pipe). However, to be sure you'd have to  
ask Jim. If you don't store DICTIONARIES in fields, there is a  
possibility that those delimiters would work, because Jim no doubt  
chose them for a reason. However, He (capitalized like the messiah)  
may be reluctant to share the internals, because it could limit his  
ability to change how they work in the future. If those delimiters  
are safe, so to speak, you may want to use a dictionary to store the  
data in your window variable.

One other possibility - and for what its worth, probably what I would  
do if the dictionary thing doesn't work, and perhaps anyway -  is XML  
tagged data. While this is still data delimited, the delimiters are  
multiple characters long, and are therefore unlikely to appear  
randomly in your data. I have used this structure under a  
supermatrix, and the performance is acceptable. To do that, store the  
data in your window variable - using the same data type coercions you  
already do (for example, changing a date to a text representation of  
the date), but store them within the window variable as tagged data.  
One advantage might be that the datatype could be recorded - and  
other info in the future if necessary

So for a record with the following ANumericField ; ATextField ;  
ADateField, your window variable could look like this:

<ANumericField DataType="Number">12345</ANumericField>
<ATextField DataType="Text">Some Text</ATextField>
< ADateField DataType="Date">12/25/2007</ADateField>

And when building your variable, you would use the tag functions and  
statements - xtag, setxtagvalue, settagparameter, xtagevalue. If you  
jam binary data in there, it might be hard to read, but the functions  
will likely still work. To make it safer (and slower), you can make a  
complex tag:

<MarksRecordObjectFormat:Field:ABinaryField DataType="Binary">Binary  
gobbledygook<MarksRecordObjectFormat:Field:ABinaryField/>

You don't have to make your tags very big before its pretty unlikely  
that they will appear in data within a 3000 record database.

One great thing about storing and accessing data this way is you can  
now sling variables around - say with drag and drop - and program  
Panorama as an Object-Relational database, where the system appears  
to have significant advantages. And you don't have to pre-engineer  
the whole thing. Tagged data is powerful that way.

Lastly, re-reading this, I've noticed that I write like pompous  
verbose ass, but screw it, life is short.

Josh

On Mar 31, 2008, at 4:19 PM, Mark Terry wrote:

> I'm experimenting with a system of clone form record edit/adds,  
> where each record's data is contained in a windowvar... each field  
> can be a tab-delim array element if garnered from an exportline().  
> ArrayBuild, lookups, etc also work, but all have their drawbacks.  
> You're right - even for my purposes, Reminderdata is unnecessary,  
> but I'm trying to get it down tight, and this is just another kink. ;)
>
> M
>
> On Mar 31, 2008, at 1:44 PM, Jeff Kozuch wrote:
>> I'm not sure what you are trying to do, but I usually export  
>> calendar info without the data in the reminder filed, then rebuild  
>> it on the fly as needed.
>>
>>
>> Jeff Kozuch
>> President, Acacia Systems
>> Apple Certified Technical Coordinator
>> Certified Member, Apple Consultants Network
>> jk at acaciasystems.com
>> http://www.acaciasystems.com
>> 562-437-7690
>>
>>
>> On Mar 30, 2008, at 3:04 PM, Mark Terry wrote:
>>> In my db of 3,000 calendar items, approximately 300 contain tab
>>> characters in the Reminder field. This screws up procedures that use
>>> exportline(), looking for a particular array element. Can anyone  
>>> think
>>> of an easy workaround? Thamks.
>>>
>>> M
>>> _______________________________________________
>>> Qna mailing list
>>> Qna at provue.com
>>> http://provue.com/mailman/listinfo/qna
>>
>> _______________________________________________
>> Qna mailing list
>> Qna at provue.com
>> http://provue.com/mailman/listinfo/qna
>
> _______________________________________________
> Qna mailing list
> Qna at provue.com
> http://provue.com/mailman/listinfo/qna

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://provue.com/pipermail/qna/attachments/20080402/eb88833a/attachment-0001.html 