AW: Installer software

[Tiemo Hollmann TB]

Hi Peter,
you don't say, which installer maker version and which LC version you are
using, but I know, that older installer maker versions don't run with LC 8.
Perhaps you try to build the installer with LC 6.
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Peter Bogdanoff
Gesendet: Freitag, 9. Dezember 2016 04:25
An: How to use LiveCode 
Betreff: Installer software

Hi,

I’m needing to create simple installers to deploy to Mac and Win desktop.

I’ve purchased in the past Economy-x-Talk Installer Maker which doesn’t seem
to open now.

Any suggestions? I’m working in OS X, but use virtual Windows 10.

Peter Bogdanoff
___
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: Installer software

[sc...@elementarysoftware.com]

Hello Peter,

I use DropDMG  for Mac delivery and Inno Setup  
 for Windows.
To make using Inno Setup simpler, I use Inno Script Studio 
 which has a wizard feature that lets you build a 
basic install script for Inno Setup.  DropDMG is a commercial product. Inno 
Setup and Inno Script Studio are both freeware with a donation option.

I’ve used DropDMG for many years and have been very happy with the way it can 
automate the process of building slick DMG files. The thing I found most 
puzzling about DropDMG was that most of the setup work is done by first 
selecting “preferences…” from the application menu.  

The thing I (first) scratched my head about with Inno Script Studio was to not 
select individual folders to include with the installer (when the wizard asked 
for additional files or folders) but to just select the main folder that also 
encompasses the .exe.  I’m still a complete beginner with Inno Script Studio 
but my experiences so far have been good.

Warmest regards,

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   http://elementarysoftware.com/
email sc...@elementarysoftware.com
office 1-800-615-0867
--



> On Dec 8, 2016, at 7:24 PM, Peter Bogdanoff  wrote:
> 
> Hi,
> 
> I’m needing to create simple installers to deploy to Mac and Win desktop.
> 
> I’ve purchased in the past Economy-x-Talk Installer Maker which doesn’t seem 
> to open now.
> 
> Any suggestions? I’m working in OS X, but use virtual Windows 10.
> 
> Peter Bogdanoff
> ___
> 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: Installer software

[Paul Hibbert]

I haven’t worked with Windows for a while, but DropDMG works well for Mac and 
is constantly updated, it’s just a one time $24 licence.

http://c-command.com/dropdmg/

You can save layouts too so you don’t have to keep going through the same 
set-up every time.

Alternatively, if it’s simple drag and drop installations then zip files work 
fine too.

Paul
p...@livecode.org

Mac OS Sierra 10.12.1



> On Dec 8, 2016, at 7:24 PM, Peter Bogdanoff  wrote:
> 
> Hi,
> 
> I’m needing to create simple installers to deploy to Mac and Win desktop.
> 
> I’ve purchased in the past Economy-x-Talk Installer Maker which doesn’t seem 
> to open now.
> 
> Any suggestions? I’m working in OS X, but use virtual Windows 10.
> 
> Peter Bogdanoff
> ___
> 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: Behaviors and the message path

[Mark Wieder]

On 12/08/2016 04:40 PM, Bleiler, Timothy wrote:


Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I 
agree, there are terrific benefits with the current implementation of the behavior 
feature. My main concern was insuring that what I observed was intended. If everything I 
described is by design, then the “inconsistencies” I noted are in my conceptual model of 
the language (extended object message path vs concatenation of scripts). Is there a 
better model that accounts for how the engine implements behaviors than an unpredictable 
combination of the two I’ve identified? An oversimplified understanding of how the engine 
processes scripts can get even experienced developers into trouble. The dictionary entry 
on "behavior" only hints at the full power of the feature and it might be 
difficult to expand it without invoking an accurate model of the engine’s rule set for 
behaviors.


I think the best explanation of the message path is still Richard 
Gaskin's chart and web page. Although I have to give props to Dar Scott 
for his message primer as well.


I tend to think of behavior scripts (and I know there are other 
viewpoints on this, so ymmv) as private backscripts fitting into the 
message path right behind the objects that use them. And in that sense 
behavior scripts have the same functionality as other library scripts:


behavior handlers extend the functionality of an object or a group of 
similar objects


behaviors can be chained: for me this makes them more useful than 
substacks, since you can't have substacks of substacks, but behaviors 
allow me to have a library with compartmentalized functionality, i.e., a 
math library with a special section for imaginary or complex numbers.


behavior handlers can be overridden: a handler in the library script is 
in the message path unless a handler of the same name is earlier in the 
message path


--
 Mark Wieder
 ahsoftw...@gmail.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

Installer software

[Peter Bogdanoff]

Hi,

I’m needing to create simple installers to deploy to Mac and Win desktop.

I’ve purchased in the past Economy-x-Talk Installer Maker which doesn’t seem to 
open now.

Any suggestions? I’m working in OS X, but use virtual Windows 10.

Peter Bogdanoff
___
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: Behaviors and the message path

[Mike Kerner]

I think I need an example, because I'm not understanding the problem that
you're having with the currentbehavior

On Thu, Dec 8, 2016 at 7:40 PM, Bleiler, Timothy 
wrote:

> > On Dec 8, 2016, at 5:09 PM, mwieder  wrote:
> >
> > I don't see these as anomalies or inconsistencies, but as features that
> help
> > implement proper object-oriented behavior. Tim- what "problems" do you
> see
> > with the way this is implemented? Am I missing something?
>
>
> Thanks Mark. I probably shouldn’t have used the word “problems” anywhere
> in my post. I agree, there are terrific benefits with the current
> implementation of the behavior feature. My main concern was insuring that
> what I observed was intended. If everything I described is by design, then
> the “inconsistencies” I noted are in my conceptual model of the language
> (extended object message path vs concatenation of scripts). Is there a
> better model that accounts for how the engine implements behaviors than an
> unpredictable combination of the two I’ve identified? An oversimplified
> understanding of how the engine processes scripts can get even experienced
> developers into trouble. The dictionary entry on "behavior" only hints at
> the full power of the feature and it might be difficult to expand it
> without invoking an accurate model of the engine’s rule set for behaviors.
>
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Behaviors and the message path

[Bleiler, Timothy]

> On Dec 8, 2016, at 5:09 PM, mwieder  wrote:
> 
> I don't see these as anomalies or inconsistencies, but as features that help
> implement proper object-oriented behavior. Tim- what "problems" do you see
> with the way this is implemented? Am I missing something?


Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my 
post. I agree, there are terrific benefits with the current implementation of 
the behavior feature. My main concern was insuring that what I observed was 
intended. If everything I described is by design, then the “inconsistencies” I 
noted are in my conceptual model of the language (extended object message path 
vs concatenation of scripts). Is there a better model that accounts for how the 
engine implements behaviors than an unpredictable combination of the two I’ve 
identified? An oversimplified understanding of how the engine processes scripts 
can get even experienced developers into trouble. The dictionary entry on 
"behavior" only hints at the full power of the feature and it might be 
difficult to expand it without invoking an accurate model of the engine’s rule 
set for behaviors.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
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: Behaviors and the message path

[mwieder]

(Different Mark here, but...)

Yes, that's by design and explicitly to allow for overriding.
It's *very* useful, for example, for setting up default behavior in a
behavior script and then selectively overriding that in some, but not all,
the objects that use that behavior script.

The issue of script-local variables only being available in the behavior
script is also by design, and is consistent with the way script-local
variables work in any script. It also enforces the scope of encapsulated
data in the objects in the message path.

I don't see these as anomalies or inconsistencies, but as features that help
implement proper object-oriented behavior. Tim- what "problems" do you see
with the way this is implemented? Am I missing something?



-
-- 
 Mark Wieder
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710943.html
Sent from the Revolution - User mailing list archive at Nabble.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: Behaviors and the message path

[Ralph DiMola]

> Tim Bleiler, Ph.D. wrote
>if the same handler name is present in the behavior script and the parent 
>script, the parent script handler is >the one that runs.

Wow! This is good to know. This could be very handy overriding a behavior 
handler for a specific control. As you said, there seems to be a message path 
conundrum here. I'm interested what Mark might have to say on this.


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 
Bleiler, Timothy
Sent: Thursday, December 08, 2016 3:24 PM
To: How to use LiveCode
Subject: Behaviors and the message path

I’m curious about what appears to me to be a confusing aspect of the 
implementation of behaviors. In short, behaviors have characteristics of an 
isolated, local extension of the message path AND characteristics of a 
concatenation of the parent control’s script. I’m raising the issue for two 
reasons: 1) to clarify how to explain behaviors to someone new to Livecode or 
just learning about the feature and 2) to question if all the features of 
behaviors are intentional or if some might be accidents of implementation and 
therefore may be eliminated in the future.

I’ve used behaviors since they were first introduced and it’s worked well for 
me to think of them as an extension of the message path from the parent 
control. However, I recently discovered that a command in a behavior script can 
directly call a handler in the parent script. Furthermore, if the same handler 
name is present in the behavior script and the parent script, the parent script 
handler is the one that runs. This capability is consistent with 
conceptualizing the behavior script as a concatenation with the parent script 
and contradicts the idea that behaviors are an extension of the message path. 

However, script level variables in a behavior are accessible only in the object 
script in which they are declared, consistent with the idea of an extended 
message path. Finally, If a handler with the same name exists in the parent 
script and a behavior script, it’s possible to execute the handler in the 
behavior either after the parent version runs or instead of the parent version 
by treating the behavior script as an independent step in the message path and 
using control structures like “pass”, “send” and “dispatch”. There may be more 
of the these types of inconsistencies but that seems more than enough to 
provoke some discussion on this list. I realize that any problems with these 
features of behaviors can easily be avoided by common sense design but some 
discussion seems warranted for the reasons I cited above. Anybody want to weigh 
in on this?

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
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

Behaviors and the message path

[Bleiler, Timothy]

I’m curious about what appears to me to be a confusing aspect of the 
implementation of behaviors. In short, behaviors have characteristics of an 
isolated, local extension of the message path AND characteristics of a 
concatenation of the parent control’s script. I’m raising the issue for two 
reasons: 1) to clarify how to explain behaviors to someone new to Livecode or 
just learning about the feature and 2) to question if all the features of 
behaviors are intentional or if some might be accidents of implementation and 
therefore may be eliminated in the future.

I’ve used behaviors since they were first introduced and it’s worked well for 
me to think of them as an extension of the message path from the parent 
control. However, I recently discovered that a command in a behavior script can 
directly call a handler in the parent script. Furthermore, if the same handler 
name is present in the behavior script and the parent script, the parent script 
handler is the one that runs. This capability is consistent with 
conceptualizing the behavior script as a concatenation with the parent script 
and contradicts the idea that behaviors are an extension of the message path. 

However, script level variables in a behavior are accessible only in the object 
script in which they are declared, consistent with the idea of an extended 
message path. Finally, If a handler with the same name exists in the parent 
script and a behavior script, it’s possible to execute the handler in the 
behavior either after the parent version runs or instead of the parent version 
by treating the behavior script as an independent step in the message path and 
using control structures like “pass”, “send” and “dispatch”. There may be more 
of the these types of inconsistencies but that seems more than enough to 
provoke some discussion on this list. I realize that any problems with these 
features of behaviors can easily be avoided by common sense design but some 
discussion seems warranted for the reasons I cited above. Anybody want to weigh 
in on this?

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
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: Build App Error with sqLite

[panagiotis merakos]

Hi Dan,

You are probably affected by bug
http://quality.livecode.com/show_bug.cgi?id=18416, which is currently
marked as NOT_FIXABLE. This happens only on OSX 10.9.x.

As a workaround, you can either copy the DbSqlite file from 8.1.0 RC2 (see
details in the bug report), or upgrade your OSX version to at least OSX
10.10 (this is a free upgrade).

Best,
Panos
--

On Thu, Dec 8, 2016 at 6:39 PM, Dan Friedman 
wrote:

> Greetings!   If I build a standalone of my project to iOS it fails if I
> have the sqLite Inclusion selected.  If it's not selected, it builds fine.
> The error I get is:
>
> There was an error while saving the standalone application
> linking for arm  (arm64) failed with duplicate symbol l001 in:
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/Standalone
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/dbsqlite
> duplicate symbol l002 in:
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/Standalone
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/dbsqlite
> ---
> (there's about 200 lines of errors I took out to spare you)
> ---
> duplicate symbol l002 in:
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/Standalone
> /Applications/LiveCode Indy 8.1.0.app/Contents/Tools/
> Runtime/iOS/Device-8_2/revdb
> ld: 66 duplicate symbols for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> Any ideas??
>
> LC Indy 8.1.0
> Mac OSX 10.9.5
> XCode 6.2
>
>
> Thank you in advance!
> -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

Build App Error with sqLite

[Dan Friedman]

Greetings!   If I build a standalone of my project to iOS it fails if I have 
the sqLite Inclusion selected.  If it's not selected, it builds fine.  The 
error I get is:

There was an error while saving the standalone application
linking for arm  (arm64) failed with duplicate symbol l001 in:
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/Standalone
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/dbsqlite
duplicate symbol l002 in:
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/Standalone
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/dbsqlite
---
(there's about 200 lines of errors I took out to spare you)
---
duplicate symbol l002 in:
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/Standalone
/Applications/LiveCode Indy 
8.1.0.app/Contents/Tools/Runtime/iOS/Device-8_2/revdb
ld: 66 duplicate symbols for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Any ideas??

LC Indy 8.1.0
Mac OSX 10.9.5
XCode 6.2


Thank you in advance!
-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

Re: Cannot get a compiled app to work

[panagiotis merakos]

Hi Greg,

Thanks for the follow up. Could you please file a bug report, including the
simplified sample stack and the .lcb file needed to create the widget?

Best regards,
Panos
--

On Thu, Dec 8, 2016 at 2:02 PM, pink  wrote:

> When I first posted, I mentioned that the program worked in the
> simulator...
> that was entirely accurate...
>
> I tested the app in the simulator, but when I went to the section where the
> SVG Text widget should have been displayed, it wasn't there. I've tried
> this
> out a few times, including just making a simple one card stack that only
> had
> that one widget in it, here are the notes from this test:
>
> The first time I clicked test and sent the app to the simulator, the app
> would open, but the widget itself was not displayed.
>
> Any subsequent time I sent the app to the simulator, the app would give me
> the splash screen and close immediately (UNLESS I restart Livecode).
>
> Regardless, my app will not work on my iPad with the widget in place,
> doesn't matter if I search for inclusions or select them myself.
>
>
>
>
>
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/Cannot-get-a-compiled-app-to-work-
> tp4710891p4710937.html
> Sent from the Revolution - User mailing list archive at Nabble.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

Re: Cannot get a compiled app to work

[pink]

When I first posted, I mentioned that the program worked in the simulator...
that was entirely accurate...

I tested the app in the simulator, but when I went to the section where the
SVG Text widget should have been displayed, it wasn't there. I've tried this
out a few times, including just making a simple one card stack that only had
that one widget in it, here are the notes from this test:

The first time I clicked test and sent the app to the simulator, the app
would open, but the widget itself was not displayed.

Any subsequent time I sent the app to the simulator, the app would give me
the splash screen and close immediately (UNLESS I restart Livecode).

Regardless, my app will not work on my iPad with the widget in place,
doesn't matter if I search for inclusions or select them myself.





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Cannot-get-a-compiled-app-to-work-tp4710891p4710937.html
Sent from the Revolution - User mailing list archive at Nabble.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

[ANN] LiveCode is on Gitter

[Peter TB Brett]

Hey folks,

The #livecode channel on the Freenode IRC network hasn't become very 
popular, so I've been looking for an alternative community instant 
messaging solution.


Several people contacted me to suggest using Gitter, so I've now set up 
a community for LiveCode users and developers:


https://gitter.im/LiveCode/

  Peter


--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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