Re: Save file dialogs...

2017-10-23 Thread Richard Gaskin via use-livecode 

Paul Dupuis wrote:

> On 10/23/2017 4:23 PM, Richard Gaskin via use-livecode wrote:
>> Trevor DeVore wrote:
>>
>> > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode <
>> > use-livecode at lists.runrev.com> wrote:
>> >
>> >> One option would be to leave the extension off when initially
>> >> presented to the user. Then add the correct extension before
>> >> saving if the user did not manually add one. It is probably a
>> >> little more complicated than that though... unless the user has
>> >> their OS set to display extensions, they may not be presented
>> >> with them normally. I’m not sure if that is detectable from
>> >> within LC though.
>> >
>> > One thing to be aware of with this approach is that it won’t work
>> > if your app is sandboxed (apps distributed through the Mac App
>> > Store are sandboxed). When sandboxed you can only write to a file
>> > path that the user explicitly specifies. You will get an error if
>> > you try to change the path that the user specified in the save as
>> > dialog.
>>
>> Good point. Thanks for that, Trevor.
>>
>> It would seem an enhancement request is in order.
>>
>> Paul, are you in a position to file that?
>
> I will file an enhancement request. I'd like to see a
> future/alternative version of ask file that provides the callbacks
> Ralph mentioned. Perhaps as an LCB widget?

Thanks in advance.  It'll be good to get that standard behavior.

If it were a new command/function, writing it with LCB using FFI would 
probably be an excellent choice.  Indeed, just about anyone in the 
community could do it.


But in this case it's an extension of an existing command built into the 
engine, so doing this feature completion in the existing engine code 
would seem maybe a better move.


After all, if it were written in LCB, we'd then have two different 
versions of some form of Ask File command, and we'd have to remember the 
nuances between them, which one has what, and if we want the LCB version 
we'd have to remember to add that component wherever it's needed.


As a feature completion of the existing engine-based command, this would 
be available to everyone always, and it's common enough to expect most 
folks will want it.  And less to remember.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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: Save file dialogs...

2017-10-23 Thread Paul Dupuis via use-livecode 
On 10/23/2017 4:23 PM, Richard Gaskin via use-livecode wrote:
> Trevor DeVore wrote:
>
> > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> One option would be to leave the extension off when initially
> >> presented to the user. Then add the correct extension before saving
> >> if the user did not manually add one. It is probably a little more
> >> complicated than that though... unless the user has their OS set to
> >> display extensions, they may not be presented with them normally. I’m
> >> not sure if that is detectable from within LC though.
> >
> > One thing to be aware of with this approach is that it won’t work if
> > your app is sandboxed (apps distributed through the Mac App Store are
> > sandboxed). When sandboxed you can only write to a file path that the
> > user explicitly specifies. You will get an error if you try to change
> > the path that the user specified in the save as dialog.
>
> Good point. Thanks for that, Trevor.
>
> It would seem an enhancement request is in order.
>
> Paul, are you in a position to file that?
>

I will file an enhancement request. I'd like to see a future/alternative
version of ask file that provides the callbacks Ralph mentioned. Perhaps
as an LCB widget?



___
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: Need an Applescript Expert

2017-10-23 Thread Ralph DiMola via use-livecode 
Shake some dust off from my Acrobat JavaScript days...
I think you will have to open the document. You are in a new instance of
Acrobat without an currently open document.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Monday, October 23, 2017 6:57 PM
To: How to use LiveCode
Cc: Bob Sneidar
Subject: Need an Applescript Expert

Hi all. 

When populating forms on a Macintosh, I figured out a nice little hack which
allows me to populate a fillable form with values using AppleScript. The
trick is to tell Applescript to tell Acrobat to run a Javascript! Seems a
little convoluted but it works great. 

So I discovered recently that Applescript can run Javascript natively!
Great. I figured I would bypass applescript and pass javascript directly!
But I've run ingo a snag. Here is a quick sample of what works:

tell application "/Applications/Adobe Acrobat DC/Adobe Acrobat.app"
set theScript to "this.getField(\"technotes\").value = \"This is only a
test. \";"
do script theScript
end tell

Don't let the backslash quotes trip you up I am just escapting quote
characters. Now the Javascript version *should* look like this but it does
NOT work!

Acrobat = Application('Adobe Acrobat');
Acrobat.activate();
delay(1);

this.getField("technotes").value = "This is only a test.";

I get an error that this.getField is undefined! Wha??? Why does it work
as an applescript command then??

Bob S



___
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

Need an Applescript Expert

2017-10-23 Thread Bob Sneidar via use-livecode 
Hi all. 

When populating forms on a Macintosh, I figured out a nice little hack which 
allows me to populate a fillable form with values using AppleScript. The trick 
is to tell Applescript to tell Acrobat to run a Javascript! Seems a little 
convoluted but it works great. 

So I discovered recently that Applescript can run Javascript natively! Great. I 
figured I would bypass applescript and pass javascript directly! But I've run 
ingo a snag. Here is a quick sample of what works:

tell application "/Applications/Adobe Acrobat DC/Adobe Acrobat.app"
set theScript to "this.getField(\"technotes\").value = \"This is only a test. 
\";"
do script theScript
end tell

Don't let the backslash quotes trip you up I am just escapting quote 
characters. Now the Javascript version *should* look like this but it does NOT 
work!

Acrobat = Application('Adobe Acrobat');
Acrobat.activate();
delay(1);

this.getField("technotes").value = "This is only a test.";

I get an error that this.getField is undefined! Wha??? Why does it work as 
an applescript command then??

Bob S



___
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: Save file dialogs...

2017-10-23 Thread Richard Gaskin via use-livecode 

Trevor DeVore wrote:

> On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> One option would be to leave the extension off when initially
>> presented to the user. Then add the correct extension before saving
>> if the user did not manually add one. It is probably a little more
>> complicated than that though... unless the user has their OS set to
>> display extensions, they may not be presented with them normally. I’m
>> not sure if that is detectable from within LC though.
>
> One thing to be aware of with this approach is that it won’t work if
> your app is sandboxed (apps distributed through the Mac App Store are
> sandboxed). When sandboxed you can only write to a file path that the
> user explicitly specifies. You will get an error if you try to change
> the path that the user specified in the save as dialog.

Good point. Thanks for that, Trevor.

It would seem an enhancement request is in order.

Paul, are you in a position to file that?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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: Save file dialogs...

2017-10-23 Thread Trevor DeVore via use-livecode 
On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One option would be to leave the extension off when initially presented to
> the user. Then add the correct extension before saving if the user did not
> manually add one. It is probably a little more complicated than that
> though... unless the user has their OS set to display extensions, they may
> not be presented with them normally. I’m not sure if that is detectable
> from within LC though.


One thing to be aware of with this approach is that it won’t work if your
app is sandboxed (apps distributed through the Mac App Store are
sandboxed). When sandboxed you can only write to a file path that the user
explicitly specifies. You will get an error if you try to change the path
that the user specified in the save as dialog.

Trevor DeVore
ScreenSteps

>
___
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: Bug with first key in dialog

2017-10-23 Thread Ludovic THEBAULT via use-livecode 

> Le 23 oct. 2017 à 16:58, Bob Sneidar via use-livecode 
>  a écrit :
> 
> If you mean in an ask dialog text field, that works for me with that same 
> version, MacOS 10.12.6
> 
> Bob S

Thanks

My bug seem the same issue as bug 20503 
 and it already resolved for 
the next release.

Ludovic
___
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: Resizing stack window by scaling

2017-10-23 Thread Jim Lambert via use-livecode 
RichardG wrote:

> One curiosity, though: what computers offer the 1536x864 resolution that 
> apparently 5.48% of users are running?  I can't recall even seeing that 
> resolution in any spec listings.

A Windows thing?
https://answers.microsoft.com/en-us/windows/forum/windows_8-performance/screen-resolution-is-lowering/a67543fb-1013-41df-82f3-476a0757627c?auth=1
 


Jim Lambert

___
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: Save file dialogs...

2017-10-23 Thread Ralph DiMola via use-livecode 
In Windows you can add a hook into the open/save file dialogs. You get call 
backs for various events including changing the file type. I don’t know about 
Mac/Linux but I would assume the same(but different) facilities exist. 
Accessing the windows hooks would of course require changes to the engine. In 
Windows you can also get a callback when the user clicks the save/open/cancel 
before the dialog is closed.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Brian Milby via use-livecode
Sent: Monday, October 23, 2017 12:32 PM
To: How to use LiveCode
Cc: Brian Milby
Subject: Re: Save file dialogs...

One option would be to leave the extension off when initially presented to the 
user. Then add the correct extension before saving if the user did not manually 
add one. It is probably a little more complicated than that though... unless 
the user has their OS set to display extensions, they may not be presented with 
them normally. I’m not sure if that is detectable from within LC though.

At least on Mac this would require a change in the engine source to have 
extensions change in the dialog.
On Mon, Oct 23, 2017 at 9:54 AM Paul Dupuis via use-livecode < 
use-livecode@lists.runrev.com> wrote:

> In our application we often provide our customers with the ability to 
> save information in a variety of formats using a code snippet such as:
>
>   put "YourData.txt" into tDefaultFileName
>   put "Save some data as:" into tPrompt
>   put the defaultFolder & tDefaultFileName into tDefaultFilePath
>   put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" 
> into tTypes
>   ask file tPrompt with tDefaultFilePath with type tTypes
>   put it & cr & the result into fld 1
>
> Note that "it" contains the file path and "the result" contains the 
> type selected (Plain Text, Word, RTF, whatever)
>
> It has been pointed out that most other application, on either OSX or 
> Windows, in a save file dialog, dynamically change the file extension 
> when a different type is selected from the save file popup menu. For 
> example, in the above code, if the use is initially presented with 
> "YourData.txt" and "Plain Text" as the type. If the user selected 
> "Microsoft Word" the extension presented in the dialog is not changed 
> to .docx dynamically. This does happen in most other commercial 
> applications (i.e. MS Word).
>
> You do get back the chosen type in the result, but only after the 
> dialog has been closed. You can use this to change the extension after 
> the fact, but apparently not dynamically.
>
> This behavior exists in at least 6.7.11 through 8.1.6 under both OSX 
> and Windows
>
> Questions for the community AND/OR the LiveCode mothership:
>
> 1) Is this a "bug"?
>
> 2) Is there any work around (like a secret callback message) to detect 
> when the popup type menu has been changed to dynamically update the 
> presented file name's extension?
>
> 3) Has anyone else in the community run into this and cares about it 
> or are my customers just being way to picky?
>
>
> ___
> 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


___
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: Save file dialogs...

2017-10-23 Thread Brian Milby via use-livecode 
One option would be to leave the extension off when initially presented to
the user. Then add the correct extension before saving if the user did not
manually add one. It is probably a little more complicated than that
though... unless the user has their OS set to display extensions, they may
not be presented with them normally. I’m not sure if that is detectable
from within LC though.

At least on Mac this would require a change in the engine source to have
extensions change in the dialog.
On Mon, Oct 23, 2017 at 9:54 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> In our application we often provide our customers with the ability to
> save information in a variety of formats using a code snippet such as:
>
>   put "YourData.txt" into tDefaultFileName
>   put "Save some data as:" into tPrompt
>   put the defaultFolder & tDefaultFileName into tDefaultFilePath
>   put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" into
> tTypes
>   ask file tPrompt with tDefaultFilePath with type tTypes
>   put it & cr & the result into fld 1
>
> Note that "it" contains the file path and "the result" contains the type
> selected (Plain Text, Word, RTF, whatever)
>
> It has been pointed out that most other application, on either OSX or
> Windows, in a save file dialog, dynamically change the file extension
> when a different type is selected from the save file popup menu. For
> example, in the above code, if the use is initially presented with
> "YourData.txt" and "Plain Text" as the type. If the user selected
> "Microsoft Word" the extension presented in the dialog is not changed to
> .docx dynamically. This does happen in most other commercial
> applications (i.e. MS Word).
>
> You do get back the chosen type in the result, but only after the dialog
> has been closed. You can use this to change the extension after the
> fact, but apparently not dynamically.
>
> This behavior exists in at least 6.7.11 through 8.1.6 under both OSX and
> Windows
>
> Questions for the community AND/OR the LiveCode mothership:
>
> 1) Is this a "bug"?
>
> 2) Is there any work around (like a secret callback message) to detect
> when the popup type menu has been changed to dynamically update the
> presented file name's extension?
>
> 3) Has anyone else in the community run into this and cares about it or
> are my customers just being way to picky?
>
>
> ___
> 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

LC8/9 Point tool selected - objects are selectable and show the edit frame but no right click menu

2017-10-23 Thread Matthias Rebbe via use-livecode 
Hi

from time to time i am experiencing on Mac OS X that although the  LC ide is in 
edit mode and although the selected objects show the “selected” frame, the 
right click menu does not show up and the mouse pointer still looks like as the 
ide is in Browse mode. I then have to delete the livecode7.rev preference file 
to get it working again.

I am not totally sure, but i think this is caused by LC9DP9. Sometimes in LC, 
while in edit mode clicking on a button still sends a mouseup, so the button 
script is executed. After this the described behaviour can be seen even after a 
restart of LC9.
Only deleting the pref file solves it.

Did anyone else noticed this?

Regards,
Matthias

___
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: Bug with first key in dialog

2017-10-23 Thread Bob Sneidar via use-livecode 
If you mean in an ask dialog text field, that works for me with that same 
version, MacOS 10.12.6

Bob S


> On Oct 23, 2017, at 07:06 , Ludovic THEBAULT via use-livecode 
>  wrote:
> 
> Hello, 
> 
> i’ve opened this bug :
> http://quality.livecode.com/show_bug.cgi?id=20595
> 
> With LV 8.17 rc3 in a dialog you couldn’t use the first key of the keyboard 
> (under the escape key)
> 
> It’s just for me or someone could confirm ?
> 
> Thanks

___
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: Widget properties

2017-10-23 Thread Bob Sneidar via use-livecode 
The answer to that question may be academic. But the best answer I can come up 
with is that mobile devices are fundamentally different than desktop devices. 
It's already an amazing thing to get a single layout to display in the various 
desktop operating systems in a consistent manner, and Windows/Mac/Unix/Linux 
are similar enough for that. iOS and Android are vastly different interfaces, 
so to look and behave "natively" on these requires in many instances a 
different kind of object. 

It is not a big chore, but you can create your own "scalable" radio buttons 
from regular buttons and some reasonably high resolution images, or even just 
the images themselves. That is one of the great things about livecode. You can 
with some ingenuity create your own custom controls. 

Bob S


> On Oct 22, 2017, at 05:35 , Pyyhtiä Christer via use-livecode 
>  wrote:
> 
> When fixing a problem with non-scaling radio buttons one solution was to use 
> widget switch button, which can be scaled.
> 
> Now it appears that those buttons do not retain the setup theme, but you need 
> to redo it at every stack startup.  Why not.
> 
> Actually the first question is why can't the LiveCode team make the radio 
> buttons scalable?  Using those on a mobile device you hardly see what the 
> hilite status is.
> 
> 
> Christer Pyyhtiä
> chris...@mindcrea.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

___
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

Save file dialogs...

2017-10-23 Thread Paul Dupuis via use-livecode 
In our application we often provide our customers with the ability to
save information in a variety of formats using a code snippet such as:

  put "YourData.txt" into tDefaultFileName
  put "Save some data as:" into tPrompt
  put the defaultFolder & tDefaultFileName into tDefaultFilePath
  put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" into
tTypes
  ask file tPrompt with tDefaultFilePath with type tTypes
  put it & cr & the result into fld 1

Note that "it" contains the file path and "the result" contains the type
selected (Plain Text, Word, RTF, whatever)

It has been pointed out that most other application, on either OSX or
Windows, in a save file dialog, dynamically change the file extension
when a different type is selected from the save file popup menu. For
example, in the above code, if the use is initially presented with
"YourData.txt" and "Plain Text" as the type. If the user selected
"Microsoft Word" the extension presented in the dialog is not changed to
.docx dynamically. This does happen in most other commercial
applications (i.e. MS Word).

You do get back the chosen type in the result, but only after the dialog
has been closed. You can use this to change the extension after the
fact, but apparently not dynamically.

This behavior exists in at least 6.7.11 through 8.1.6 under both OSX and
Windows

Questions for the community AND/OR the LiveCode mothership:

1) Is this a "bug"?

2) Is there any work around (like a secret callback message) to detect
when the popup type menu has been changed to dynamically update the
presented file name's extension?

3) Has anyone else in the community run into this and cares about it or
are my customers just being way to picky?


___
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: SOLVED Re: HELP - Script debugger out of sync

2017-10-23 Thread Bob Sneidar via use-livecode 
Unseen characters have bitten a few of us. I copy/pasted from LC to SimpleText 
and back again and that fixed all my issues. I think the transition to unicode 
is what did it. 

Bob S


> On Oct 20, 2017, at 23:55 , James Hale via use-livecode 
>  wrote:
> 
> After i sent my post I wondered if perhaps there were unseen gremlins in the 
> script.
> 
> I copied it out and pasted into BBEDIT and  "Zap(ped) gremlins" (one of my 
> favourite BBEDT commands).
> 
> Pasted the zapped script back into LC and everything was back in sync.
> 
> How I ended up with some unseen characters in the script I do not know but 
> they are gone now and all is well.
> 
> Sorry for the disturbance.
> 
> 
> James
> 
> 
> 
> 
> 
> ___
> 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

Bug with first key in dialog

2017-10-23 Thread Ludovic THEBAULT via use-livecode 
Hello, 

i’ve opened this bug :
http://quality.livecode.com/show_bug.cgi?id=20595

With LV 8.17 rc3 in a dialog you couldn’t use the first key of the keyboard 
(under the escape key)

It’s just for me or someone could confirm ?

Thanks
___
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

[ANN] This Week in LiveCode 103

2017-10-23 Thread panagiotis merakos via use-livecode 
Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #103 here: https://goo.gl/R2KgPk

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.


-- 
Panagiotis Merakos 
LiveCode Software Developer

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

[ANN] Release 9.0.0 DP-10

2017-10-23 Thread panagiotis merakos via use-livecode 
Dear list members,

We are pleased to announce the release of LiveCode 9.0.0 DP-10.


Developer Preview Release
=
Warning: this is not a stable release.  Please ensure that you back up your
stacks before testing them.

Getting the Release
===
You can get the release at https://downloads.livecode.com/livecode/ or via
the automatic updater.

Release Contents

LiveCode 9.0.0 DP-10 comes with 27 bugfixes. Moreover, more than 40
bugfixes that were fixed in LiveCode 8.1.x and 8.2.x, are now merged into
LiveCode 9.0.0 DP-10.

In addition, LiveCode 9.0.0 DP-10 includes several amazing new features:

- Java-FFI: Added support for custom classes (.jar files) in desktop and
android apps
- Java-FFI: Use extensions' code folders to update jarfiles standalone
setting
- LCB-Engine: Enabled getting the caller from LCB
- LCB-Language: Implemented send { command | function }  and post
 LCB syntax for libraries
- Implemented Native Scrollers for Datagrid object
- Implemented a HTML5 deploy library


Known issues

- The Browser widget can cause hang in the IDE in some Linux distros - see
http://quality.livecode.com/show_bug.cgi?id=19658

- The Android Native Button widget uses "labelColor", not
"foregound"/"textColor" to set the text color

- You might not be able to run HTML5 standalones locally using the most
recent version of Safari or Chrome (Firefox is OK). This is due to those
browsers now prohibiting cross-origin-requests. To test out standalones
locally using these browser, we suggest using a local HTTP server as
described in the HTML5 deployment guide. However, this will not be a
problem if you use the new HTML5 deployment library, which does this for
you: You just have to choose one of the installed browsers (click on the
"Development -> Test Target" menu item), and then click on the "Test"
button.

- [Business Only] If you use the new feature of HTML5 deployment from the
"Test" button, make sure you have unchecked "Script Debug Mode". See bug
http://quality.livecode.com/show_bug.cgi?id=20584

The full release notes are available from:

http://downloads.livecode.com/livecode/9_0_0/LiveCodeNotes-9_0_0_dp_10.pdf

Note: Due to the changes in LCB  and , if your custom widgets
use these commands, you have to rebuild them in LC 9 DP-10 using the
Extensions Builder.

Feedback

Please report any bugs encountered on our BugZilla at
http://quality.livecode.com/

We have a forum available for discussing LiveCode Builder at
http://forums.livecode.com/viewforum.php?f=93

Have fun!

The LiveCode Team
--
___
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