On Thursday, June 26, 2003, at 07:22 AM, wouter wrote:
All this is why I suggested in one of the bugreports to add something like a "binary" field to Metacard.In most cases a custom property in the owner of the potential field might be more appropriate. (The question I brought up earlier this week on per-card non-displayed background data, takes a wee bit more thinking.)
If a field is used, then using base64Encode() and base64Decode() to format the data should allow it to work for storage, even under today's conditions. If you prefer hex, you should be able to roll your own hex encoding using binaryEncode() and binaryDecode(), which might be more convenient for debugging. Preview copies of my free "boxes" library are out and I hope to announce that soon; it will allow complex data to be put into fields, but field storage is best suited for debugging.
Given that...
I think good handling of long words in wrapping is desirable and it may not even need a special mode.
And even though I don't like the idea of storing binary data in a field, it might be done in quick debugging lines and we might do it accidently, so I would support something reasonable happening. This means that nothing weird happens with null (or any other control characters). This means no line limit. This means wrapping works for any kind of data. This means no crashing. Even with unicode. This means documentation warnings can be removed. There would be no need for a "binary" field under these conditions.
I don't know how efficient field storage is. It might be that if there are no unicode characters and there are no per-char properties set that it is relatively efficient. Even so, I would think a custom property would be more efficient as far as space and speed, but I don't know for sure.
Dar Scott
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
