Re: "LabVIEW" control broken because of Leopard "Unicode text" (?)
Re: "LabVIEW" control broken because of Leopard "Unicode text" (?)
- Subject: Re: "LabVIEW" control broken because of Leopard "Unicode text" (?)
- From: has <email@hidden>
- Date: Tue, 27 Nov 2007 18:40:44 +0000
Philip Aker wrote:
On 2007-11-19, at 01:03, Chris Prall wrote:
What seems to be the problem is that LabVIEW requires the historic
"string" type with simple ASCII names.
AppleScript v2.0 in Leopard now makes all "string" classes
equivalent to "Unicode text"
Is there some way to create or coerce a variable argument
equivalent to the historic "sting" type ??
You can try:
tell application "LabVIEW"
RunVI {"test.vi" as «class utf8»}
end tell
Won't do anything; AppleScript still packs the string as
typeUnicodeText. Even if it did pack it as typeUTF8Text I'd be willing
to bet LabVIEW would still throw an error. The likely cause of this
problem is that LabView is extracting the supplied Apple event
parameter as-is, then throws an error if it isn't the type it
requires. The correct approach is for the application to ask the Apple
Event Manager to coerce the parameter to the required type while
extracting it; see AEGetParamDesc's desiredType argument.
First thing the OP should do is file a bug report with the LabVIEW
developers, as this is something they need to fix at their end for
future releases.
Second thing is to find a viable workaround for current LabVIEW
releases.
AS2.0 doesn't appear to provide a specific method for forcing text
values to pack as typeChar, which really limits your options there.
The only possibility I can find is to write string literals in raw
«data TEXT...» form, although that's ugly, undocumented behaviour and
won't do you any good if the strings you're using aren't being
supplied as literals.
Other possibilities would be:
- Write an osax that forwards commands to applications, packing their
text parameters as typeChar; e.g. 'send command to "LabVIEW" with
direct parameter {"test.vi"}. This will also look a bit ugly, plus
you'll need to know some C to do this, but at least it'll let you
continue using AppleScript for everything else.
- Use another language/bridge in place of AppleScript. For example,
appscript (see my sig for links) provides various mechanisms for
dealing with recalcitrant applications such as this. Python appscript
currently packs Python's 'string' values as typeChar and 'unicode'
values as typeUnicodeText, allowing you to use strings directly:
#!/usr/bin/python
from appscript import *
LabVIEW = app('LabVIEW')
LabVIEW.RunVI(['test.vi'])
Ruby and ObjC appscript normally pack all text as typeUnicodeText;
however, their open design allows you to customise that behaviour on a
per-app-object basis; for example:
#!/usr/bin/ruby
require 'appscript'
include Appscript
LabVIEW = app('LabVIEW')
module PackStringAsTypeChar
def pack(val)
return val.is_a?(String) ? super.coerce(KAE::TypeChar) : super
end
end
LabVIEW.AS_app_data.extend(PackStringAsTypeChar)
LabVIEW.RunVI(['test.vi'])
Or you could try Scripting Bridge, but given its tendency to fall down
at even minor application quirks, you'll likely have to faff about
with NSAppleEventDescriptors and SB's 'raw' -sendEvent:id:parameters:
method in order to make it do what you want.
HTH
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden