Command-ctrl-shift-4 (adding the control key captures to the clipboard instead
of to file) then when the cross-hairs are visible click the space key and move
the mouse to select a window to be captured rather than the entire desktop. If
you throw in the option key when you click the mouse to do
On Mon, Nov 7, 2016 at 10:00 PM, Alan wrote:
> Does anyone know of a way I can get an iPad Pro screenshot using OSX
> 10.9.5? i.e. using a Simulator?
can't you just take a screenshot on the iPad? home button plus that 'hold'
button on the side.
Stephen Barncard - Sebastopol Ca. USA -
mixstre
On Mon, Nov 7, 2016 at 10:21 PM, stephen barncard <
stephenrevoluti...@barncard.com> wrote:
> can't you just take a screenshot on the iPad? home button plus that
> 'hold' button on the side.
>
oh. on a simulator.
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
On the Mac you can type command/shift/4 to grab a portion of the screen—you
click and drag out a rectangle; press the escape key to cancel. It leaves a PNG
on your desktop.
Peter
On Nov 7, 2016, at 10:00 PM, Alan wrote:
> 9skg+U=
> x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(1001902
Does anyone know of a way I can get an iPad Pro screenshot using OSX 10.9.5?
i.e. using a Simulator?
I think it's not possible and that I'll have to upgrade my system, XCode etc in
order to make this screenshot for an about-to-be released app? But I'd rather
not go down that route, if at all
Using LC 8.1 on iOS I'm trying to get my app to not sleep so that I can
continue to receive location updates for path tracking etc.
However, when the phone goes to sleep or the phone is manually locked, then the
location updates (locationChanged) messages no longer appear to be
received/sent.
Monte Goulding wrote:
> For most of the issues this thread is discussing though I actually
> don’t think the main thing we need is UUIDs. We *think* we need UUIDs
> only because we are used to thinking of object references as strings.
> If we have an object reference (think `is strictly an object
> On 8 Nov. 2016, at 6:24 am, Richard Gaskin wrote:
>
> > Using the long id to refer to stacks works (or at least should work)
> > for all situations except for stacks that haven't yet been saved to
> > disk. And for those stacks I would suggest storing the creation
> > timestamp as a custom pro
Sannyasin,
There are 2 downloads, one is the SDK and Studio/IDE the other download is just
the SDK. I downloaded just the SDK and followed the tutorial. I used to
download all sorts of stuff in the SDK but the tutorial enumerates the modules
that need to be downloaded. It save a lot of time and
The online tutorial asks mac users to install the latest JDK -- done
then gives this URL
https://developer.android.com/studio/index.html
for the Android SDK.. but it links to a completely new IDE: Android Studio… and
nothing matches the LC lesson on this any more…
hmmm what to do: lesson onlin
I am using Jan Shenkel's PDF Library in a project, and need to display
negative numbers in a table in red.
It seems to be possible to affect the entire table, but how can I apply
color commands to a specific cell?
TIA,
~Roger
___
use-livecode mailing lis
mwieder wrote:
> Using the long id to refer to stacks works (or at least should work)
> for all situations except for stacks that haven't yet been saved to
> disk. And for those stacks I would suggest storing the creation
> timestamp as a custom property on creating a new stack so that they
> can
mwieder wrote:
> I thought script-only stacks had to be separate files. I didn't
> realize they could be attached as substacks and bound into standalone
> apps. That does make a difference.
Hmmm...I'm not sure that they can. For a script-only stack to be truly
script-only, it would need to be s
app.
Richard Gaskin wrote
> This can't be stressed enough.
>
> The only difference between script-only stacks and traditional binary
> stacks is what's stored when saving.
OK - I stand corrected then.
I thought script-only stacks had to be separate files. I didn't realize they
could be attached
Mark-
Those are (mostly) all good points.
But the problem that concerns me is not when I have done something stupid
and end up with two stacks of the same name competing for memory space, but
when the IDE suddenly pops up the warning message and I have no idea what
has just happened. At that poin
Mark Waddingham wrote:
> The engine has always been 'okay' (I believe) with substacks of the
> same name when they are owned by *different* mainstacks - the only
> rule you must follow in your code is that if you are referencing a
> substack when the 'defaultStack' is not the main stack owning it
Ben Rubinstein wrote:
> On 07/11/2016 16:52, Richard Gaskin wrote:
>> On the one hand, each array access requires a small amount of
>> overhead to run the key through a hash to find the value's address.
>> However, that overhead is pretty small...
>
> No, no - the meat here is this:
>
>> do
On 2016-11-05 19:28, Richard Gaskin wrote:
I've grown weary of stack name conflict over the years, and this
morning decided to take some time to assess where we're really at with
that and see if perhaps there's a way to handle things more liberally
than how the IDE does now.
That is, once we mod
On 07/11/2016 16:52, Richard Gaskin wrote:
But more seriously, the meat here is this:
doSomething item viUserID of tRec, item viUserName of tRec
...vs:
doSomething aData["User ID"], aData["User Name"]
On the one hand, each array access requires a small amount of overhead to run
the ke
Richard,
Thanks for the pithy explanation! I think the most import thing for the
developer's design philosophy in your narrative is:
"This may be useful for allowing ephemeral data to be bound to such a stack
at runtime, safely refreshed with each session by virtue of never having
been saved at a
On Mon, Nov 7, 2016 at 8:52 AM, Richard Gaskin
wrote:
> There's your first bug right there - that should be:
>
> do makeAccessVars("emacs", line 1 of tTSVdata)
>
damned heretics are everywhere . . .
:)
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
Ben Rubinstein wrote:
> So the typical routine is something like
>
>do makeAccessVars("vi", line 1 of tTSVdata)
There's your first bug right there - that should be:
do makeAccessVars("emacs", line 1 of tTSVdata)
(Ducking from Mark Wieder who will no doubt groan at the pun )
But mo
Mark Waddingham wrote:
> The point here is that the purpose of script-only stackfiles is
> purely that of storage - storage in a form which means they work
> well with version control such as git.
This can't be stressed enough.
The only difference between script-only stacks and traditional bina
Ben Rubinstein wrote:
> No overtones intended by use of word "trying"! I should have said
> "experimenting with" or similar...
No offense taken, I just want to be sure that my glee for discovering
the soundness and simplicity of the engine's handling of this does not
mean I recommend relying o
On 07/11/2016 15:02, Richard Gaskin wrote:
Ben Rubinstein wrote:
(Re Mike and Mark's comments, if it's a small thing I'll use an
array; but for large quantities of data - I'm often dealing with
very large files, and after calling this function will loop over
tens or hundreds of thousands of row
Hi Panos,
bingo! I am using Valentina4, which seems not to be 64 bit compatible.
Deselecting it, the 64-bit standalone works fine.
Thanks for the quick guess!
Tiemo
-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von panagiotis merako
Hi Richard,
No overtones intended by use of word "trying"! I should have said
"experimenting with" or similar...
I am interested though that you noted, if I understood correctly, that your
experiment showed that having two substacks with the same name didn't cause an
issue in the IDE when us
Ben Rubinstein wrote:
> Currently if I understand it correctly there are issues which seem
> just too hard to fix: so instead
> http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious
> of these issues - was 'fixed' by adding the check that Richard's
> trying to remove.
In all fairn
Hi Tiemo,
A rough guess is that you have added an inclusion/external which is not
supported in OS X 64 bit (maybe revVideoGrabber?).
Otherwise I suggest you file a bug report :)
Best,
Panos
--
On Mon, Nov 7, 2016 at 2:53 PM, Tiemo Hollmann TB
wrote:
> Hello,
>
>
>
> OS X 10.11. LC 8.1.1 When I
Ben Rubinstein wrote:
> (Re Mike and Mark's comments, if it's a small thing I'll use an
> array; but for large quantities of data - I'm often dealing with
> very large files, and after calling this function will loop over
> tens or hundreds of thousands of rows using the variables - I feel
> the
Hello,
OS X 10.11. LC 8.1.1 When I create a 64-bit standalone from my main program,
I can't start the standalone. When double clicking the .app there is a short
flickering, but nothing, just nothing happens. When creating a 32-bit
standalone of the same program, it starts quite normal. 64-bit s
It's easy to dynamically create and set the values of variables, using the
"do" command, e.g.:
do format("put tValue into %s", tVarName)
I do lots of work with TSV files, which have a first row of field names, and
for years have used a function like this to create local variables, name
On 06/11/2016 20:50, Monte Goulding wrote:
On 7 Nov. 2016, at 3:57 am, Mark Wieder wrote:
Now rename the second stack to "Untitled 1"
The property inspector allows this, but now gets very confused.
Ah… well that’s probably a bug. If the IDE can’t handle multiple stacks with
the same name
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 #58 here: https://goo.gl/ZHwIjZ
This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around
On 06/11/2016 12:44, Richmond wrote:
I wonder if there is a way to replace this:
set the unicodeText of fld "fDECODE" to (numToCodePoint(107) &
numToCodePoint(104))
with this:
*put (numToCodePoint(107) & numToCodePoint(104)) into fld "fDECODE"*
where /(numToCodePoint(107) & numToCodePoint(1
On 2016-11-05 16:04, Sannyasin Brahmanathaswami wrote:
But, am I the only on that thinks this is odd behavior? If I am right,
doesn't it break the "write, run with no compile" principle of
LiveCode? If I edit the script of a binary stack, those changes are
immediately implemented. Should it not
Hi,
Sannyasin Brahmanathaswami wrote
> ERGO conclude: editing a script only stack and saving it does *not* update
> the "live" version of that file in memory that is in use by the engine.
I'd assume this to be legit & desired behavior. Imagine, your StandAlone
loads an utility stack from the web
37 matches
Mail list logo
