Re: Char Set on Custom Properties

[Mark Waddingham]

On 2015-09-03 21:38, J. Landman Gay wrote:

Returning to this topic...we are in the process of creating new stacks
in LC 7 while still running older LC 6 stacks with the same app.
Stacks have custom properties containing text created on a Mac, and my
app uses MacToISO() to display the text when running on Windows.

Some of the LC 6 stacks will be edited and saved in LC 7, others will
remain as LC 6 for a while. My app needs to know whether the character
set has already been converted so it can display text correctly. Is
there a way to tell in a script?


Hmmm - this is somewhat tricky.

From what you are saying you want people to be able to edit content in 
both LC6 and LC7, the content itself being saved in LC6 format. i.e. You 
want to move your system forward to LC7, but you need to still support 
LC6 clients and editors. Is that correct?


Now, LC7 will assume that custom property values coming from LC6 format 
stacks are binary data thus won't do anything magical with them. 
However, as soon as you pass that value through anything text-related in 
LC7 and set the custom property back, it will be (in memory at least) 
stored as text. Then, when you save the stackfile in LC6 format the 
engine will convert the text to the platform encoding and save as binary 
(which is what LC6 expects).


Of course, having just written that there might not be a problem here. 
If you are still intending to save all your stacks in LC6 format then it 
should be fine. You still need to do macToIso / isoToMac in LC7 since it 
will only be loading things in LC6 format - a problem would only arise 
if you were sometimes saving your content stacks in LC7 format.


In terms of moving forward what you might want to consider is 
transitioning to storing your text in custom properties in UTF8 format. 
So, rather than using macToIso / isoToMac you decode the UTF8 into text 
in both LC6 and LC7. This means you can continue to use LC6 format, but 
at some point in the future ditch LC6 support and then you'll be able to 
start using unicode in your text without any problems. (To be fair, you 
could still do that now - its just that in LC6 clients / editors, any 
unicode characters would appear as ? as they wouldn't be in the native 
encoding).


Hopefully that's not too confusing :S

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[Robert Brenstein]

Not an ellegant approach but have you considered having a custom 
property in your stacks that identify them for you. It sounds like 
you are in control when those stacks are created and updated, so it 
might work.


RObert

On 04.09.2015 at 13:38 Uhr -0500 J. Landman Gay apparently wrote:
Barring that, I thought of reading a sequence of bytes from the 
stack file, but I can't because these stacks are streamed remotely 
and have no filename. I don't believe there's way to read the raw 
binary content of a stack in RAM, so I'm kind of stuck.


Is there some kind of scripted test that might determine the 
stackfileVersion of any particular stack in RAM?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[J. Landman Gay]

On 9/4/2015 7:57 AM, Mark Waddingham wrote:

 From what you are saying you want people to be able to edit content in
both LC6 and LC7, the content itself being saved in LC6 format. i.e. You
want to move your system forward to LC7, but you need to still support
LC6 clients and editors. Is that correct?


Pretty much. There are hundreds of stacks out in the field, in use by 
end users. We're starting to move to LC 7 and I'll build an app 
eventually with that version, which all users will update to. New stacks 
created from now on will be made in LC7 (if all goes well; there are 
some issues I'll be reporting.) The LC7 app can read both the existing 
LC6 stacks and the new LC7 stacks, which is good, but my scripts need to 
know whether to use MacToISO() or not before displaying the text.




Now, LC7 will assume that custom property values coming from LC6 format
stacks are binary data thus won't do anything magical with them.
However, as soon as you pass that value through anything text-related in
LC7 and set the custom property back, it will be (in memory at least)
stored as text. Then, when you save the stackfile in LC6 format the
engine will convert the text to the platform encoding and save as binary
(which is what LC6 expects).


Right, I think I understand that part. The problem is that we have many 
LC6 stacks in use and new LC7 ones coming out, so the scripts need to 
know which type they're working with. It sounds like the engine bases 
its decision on the stackfileVersion saved with any particular stack, 
which would be fine for me too if we could access that, but right now 
its only a global property. I could really use a "stackfileVersion of 
this stack" command right now. That would solve the problem.


Barring that, I thought of reading a sequence of bytes from the stack 
file, but I can't because these stacks are streamed remotely and have no 
filename. I don't believe there's way to read the raw binary content of 
a stack in RAM, so I'm kind of stuck.


Is there some kind of scripted test that might determine the 
stackfileVersion of any particular stack in RAM?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[J. Landman Gay]

On 9/4/2015 1:46 PM, Robert Brenstein wrote:

Not an ellegant approach but have you considered having a custom
property in your stacks that identify them for you. It sounds like you
are in control when those stacks are created and updated, so it might work.


It hadn't occured to me, actually. I could only set the property on the 
new LC7 stacks since we have all those others out in the field already, 
but that would be enough. Thanks for the idea.


I'm having a bit of a "duh" moment here.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[J. Landman Gay]

Returning to this topic...we are in the process of creating new stacks 
in LC 7 while still running older LC 6 stacks with the same app. Stacks 
have custom properties containing text created on a Mac, and my app uses 
MacToISO() to display the text when running on Windows.


Some of the LC 6 stacks will be edited and saved in LC 7, others will 
remain as LC 6 for a while. My app needs to know whether the character 
set has already been converted so it can display text correctly. Is 
there a way to tell in a script?



On 7/23/2015 7:38 AM, Mark Waddingham wrote:

LC 7 knows the difference between binary and text - this is retained
when saving custom props (if you save in 7+ format).

The only rub is that for existing stacks in the old format custom
props will be taken to be binary data (which auto converts to text
assuming the native encoding). Thus you will need to still do the
charset translation there for the props that are text. If you then
textdecode that and set the property to the result and save in lc7
format then it will then be treated as text in future (so no charset
translation is required in future).

Sent from my iPhone


On 22 Jul 2015, at 22:06, Dan Friedman 
wrote:

Hello!   Way back in LiveCode 5 and 6, custom properties were not
ported to the proper character set when you opened the stack on a
different platform (Mac --> Win or Win --> Mac).  This was easily
solved by a simple macToISO() or ISOtoMac().   However, it appears
that LC 7.x is now doing this char mapping for custom properties on
it's own.  Before I modify a mountain of code, can anyone confirm
that LC 7+ automatically maps custom properties to the proper char
set for the host platform?

Thanks! Dan ___
use-livecode mailing list use-livecode@lists.runrev.com Please
visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___ use-livecode mailing
list use-livecode@lists.runrev.com Please visit this url to
subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[Mark Waddingham]

LC 7 knows the difference between binary and text - this is retained when 
saving custom props (if you save in 7+ format).

The only rub is that for existing stacks in the old format custom props will be 
taken to be binary data (which auto converts to text assuming the native 
encoding). Thus you will need to still do the charset translation there for the 
props that are text. If you then textdecode that and set the property to the 
result and save in lc7 format then it will then be treated as text in future 
(so no charset translation is required in future).

Sent from my iPhone

 On 22 Jul 2015, at 22:06, Dan Friedman d...@clearvisiontech.com wrote:
 
 Hello!   Way back in LiveCode 5 and 6, custom properties were not ported to 
 the proper character set when you opened the stack on a different platform 
 (Mac -- Win or Win -- Mac).  This was easily solved by a simple macToISO() 
 or ISOtoMac().   However, it appears that LC 7.x is now doing this char 
 mapping for custom properties on it's own.  Before I modify a mountain of 
 code, can anyone confirm that LC 7+ automatically maps custom properties to 
 the proper char set for the host platform?
 
 Thanks!
 Dan
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Char Set on Custom Properties

[Mark Schonewille]

Hi Dan,

Not exactly. All text is now unicode. If you set a custom property to 
the text of a field, it is unicode already. When you set the text of a 
field to a property, it is again unicode. This avoids the need for 
mapping and other hacks.


I haven't tested this much. I can imagine that this is confusing, 
particularly if you work with stacks on both old and new formats. If you 
only use the new format, however, it is very convenient and you will 
quickly get used to it.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book Programming LiveCode for the Real Beginner 
http://qery.us/3fi


LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

On 7/22/2015 23:06, Dan Friedman wrote:

Hello!   Way back in LiveCode 5 and 6, custom properties were not ported to the 
proper character set when you opened the stack on a different platform (Mac -- 
Win or Win -- Mac).  This was easily solved by a simple macToISO() or ISOtoMac(). 
  However, it appears that LC 7.x is now doing this char mapping for custom 
properties on it's own.  Before I modify a mountain of code, can anyone confirm that 
LC 7+ automatically maps custom properties to the proper char set for the host 
platform?

Thanks!
Dan



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Char Set on Custom Properties

[Dan Friedman]

Hello!   Way back in LiveCode 5 and 6, custom properties were not ported to the 
proper character set when you opened the stack on a different platform (Mac -- 
Win or Win -- Mac).  This was easily solved by a simple macToISO() or 
ISOtoMac().   However, it appears that LC 7.x is now doing this char mapping 
for custom properties on it's own.  Before I modify a mountain of code, can 
anyone confirm that LC 7+ automatically maps custom properties to the proper 
char set for the host platform?

Thanks!
Dan
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode