You didn't misunderstand, that is (almost) exactly what I'm suggesting
(once we had import/export for all objects), although I think the way set
works should probably be tweaked so that we *don't* do any manual fettling
- we just document that setting certain groups of properties via the
properties
Looking at the source, when a stack is saved, here is the general flow for
an individual widget (widget.cpp):
OnSave called to get internal widget state (array)
Write uint1 OT_WIDGET to indicate a widget
Save the object state
Save the widget kind
Save the internal widget state
Save the property se
I’m not sure I follow. The proposal I’m making is no different than what
the engine does today, just allowing the same information to be saved to an
array. The internal state of the widget is the same as what would be used
on export/import. It just adds the other properties (rect, ...) to the
ar
Exactly... that would be the overwrite option I was thinking about.
import object from array tMyArray [with OverwriteID]
import object from array tMyArray [with AutoID]
If neither option specified and the ID exists, an error would be thrown.
On Sun, Feb 25, 2018 at 9:52 PM Monte Goulding via use-
> Brian M. wrote:
> My 0.02 is that export should mirror what the engine saves to the stack
> file such that import could exactly recreate an object (with some logic on
> how to handle ID collisions - overwrite, throw error, assign new ID...)
If you are developing and testing a widget this would m
> On 26 Feb 2018, at 2:47 pm, Brian Milby wrote:
>
> My 0.02 is that export should mirror what the engine saves to the stack file
> such that import could exactly recreate an object (with some logic on how to
> handle ID collisions - overwrite, throw error, assign new ID...)
Yes that makes s
My 0.02 is that export should mirror what the engine saves to the stack
file such that import could exactly recreate an object (with some logic on
how to handle ID collisions - overwrite, throw error, assign new ID...)
On Sun, Feb 25, 2018 at 9:21 PM Monte Goulding via use-livecode <
use-livecode@l
> On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode
> wrote:
>
>> No there isn't, because if you aren't using it to completely import an
> object (i.e. set the properties of obj1 to the properties of obj2) it's
> your lookout what properties you include in the array to set - so just
> don
["hhMockup" is an enhanced version of the stack I used to produce the demos for
my LCGlobal talk "Perspective and affine transformations of images" in Nov
2017.]
The stack contains a *very fast* version of the perspective image-transformation
given in Raspberry Pi stacks collection #85 (pure LC S
On 2/25/18 1:57 PM, Richmond Mathewson via use-livecode wrote:
I want to send a rawKeyDown signal that fakes typing on the key on my
keyboard
that has the underlying rawKey code of 113.
What does this give you on a non-US keyboard (untested):
type numToChar(113)
--
Jacqueline Landman Gay
>
>
> > If we have export for all object types, there's no
> > reason (other than backwards compatibility) that the properties property
> > couldn't return the value of every single gettable property of an object
> > type.
>
> Yes there is. If we include all the different forms of text for example
Monte wrote:
> I think probably the VCS use-case is a non-issue right now.
Agreed.
>> If we have export for all object types, there's no
>> reason (other than backwards compatibility) that the properties
>> property couldn't return the value of every single gettable property
>> of an object ty
> On 26 Feb 2018, at 2:57 am, Ali Lloyd via use-livecode
> wrote:
>
> The trick is to ensure that the VCS use-case
> can be extricated.
I think probably the VCS use-case is a non-issue right now. I’m not sure if
anyone is still using lcVCS but script only stacks + stackFiles with no scripts
11 years ago there was a discussion involving "SendKeys()"
http://use-livecode.runrev.narkive.com/9tOIimV9/simulating-keystrokes
but I can find no mention of this in the LiveCode documentation.
Richmond.
On 25/2/2018 10:02 pm, Mike Bonner via use-livecode wrote:
If you add rawkeydown handlers
If you add rawkeydown handlers to your field, and then use the "type"
command to type into them, you'll trap the key code being sent (which will
always be the same for q no matter the keyboard) but there is then no
relationship to the actual key on the keyboard that I can see.
As for your 2 field
Here we go again: I reply to my own posting:
So: I have 2 fields and a button; the button having this sort of script:
on mouseUp
put empty into fld "fff"
select after fld "fff"
type "q"
end mouseUp
and the cardScript of the stack having this sort of script:
on rawKeyDown RD
put emp
That looks like a good way to start (even though it is the wrong way round).
The next questions (now I'm on a roll, I'll keep rolling) are these:
1. How do I type a rawKey command? I probably cannot.
2. If I have a script that runs type "q" how do I trap therawKeyDown and
the rawKeyUp codes
Ha, Ha: I do know how my keyboard is laid out.
I know, for instance, that if I hit the "q" key I get a raw key code of 113.
What I don't know is what "Walid" in Lahore will get when he hits the
key on his Mac/Win/Linux keyboard
when he hits the key that yields a raw key code of 113 and is in th
Thank you for the responses. So, took a step too much in the future.
Let you know how it goes with Xcode 9.2. Amazing learning by trying.
Christer Pyyhtiä
MindCrea Ltd
chris...@mindcrea.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
See the dictionary entry for the "type" command. This sends
rawKeyUp|rawKeyDown messages
This might let you construct a stack that "calibrates" (or whatever you
want to call it) what keys on any keyboard generate what keyDown number
and what characters
On 2/25/2018 5:09 AM, Richmond Mathewson vi
My apologies. I assumed you knew how the keyboard was laid out on your
mac. For other peoples macs, you might read this page.
https://stackoverflow.com/questions/21597804/determine-os-x-keyboard-layout-input-source-in-the-terminal-a-script
.
(goes off to napland)
On Sun, Feb 25, 2018 at 11:06 AM,
That's great, but I'm currently working on a Macintosh.
Richmond.
On 25/2/2018 7:38 pm, Mike Bonner via use-livecode wrote:
Just realized, if all you need to know (On linux) is the basic keyboard
information, you can likely do this..
put url "file:/etc/default/keyboard" into
and then parse it
Just realized, if all you need to know (On linux) is the basic keyboard
information, you can likely do this..
put url "file:/etc/default/keyboard" into
and then parse it. Mine contains
KBMODEL="pc105"
KBLAYOUT="us"
KBVARIANT=""
KBOPTIONS=""
BACKSPACE="guess"
On windows, if the system has powersh
Ali Lloyd wrote:
> Richard wrote:
>> For example, taking the delta between two objects gives you a great
>> way to concisely express what would be needed to reproduce one from
>> the other. Such conciseness is esp. useful in Internet applicationsL
>
> These seem to me to be perfect examples of wh
That is rather strange. Most of the time LC is exactly what I expect, but
then there are those head scratcher issues that keep me flummoxed. <--
(word of the day)
On Sun, Feb 25, 2018 at 9:57 AM, jbv via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On Sun, February 25, 2018 5:36 pm, Mi
On Sun, February 25, 2018 5:36 pm, Mike Bonner via use-livecode wrote:
> Ah, well the only useful part of my answer then would regard the first
> issue. The result remaining empty was the correct response because the
> base url was valid, so the command didn't fail to connect to the url, and
> no 4
Ah, well the only useful part of my answer then would regard the first
issue. The result remaining empty was the correct response because the base
url was valid, so the command didn't fail to connect to the url, and no 404
type or other type errors were returned as part of the headers.
As for the
Hmm. On linux you might be able to use a shell command to get some info,
though I don't know enough about theh output to be much help.
the command xkbcom :0 - dumps a truckload of info, might be useful for your
task.
I'm guessing there is a way to do this on macos too but I don't currently
have a
>
> My interest this morning came from a property sheet I build some years
> ago as an alternative to an inspector. There are many good reasons why
> a property sheet is a much better fit for an IDE, but we can save that
> for another thread.
>
> Another reason Kevin asked Scott Raney to add "the
Mike
Thanks for your reply.
Actually, in the 2 cases I mentioned, I was able to find the origin of the
problem.
The only point I was trying to make is that each time the result was of no
help since it remained empty.
On Sun, February 25, 2018 3:48 pm, Mike Bonner via use-livecode wrote:
> In the f
Either I did not explain things very well or you got hold of the wrong
end of the stick
(or, most probably a bit of both: probably the latter as a consequence
of the former).
Imagine, if you will, I need to know what an end-user's standard
keyboard layout is.
Let's call our theoretical end-use
In the first case, I would check all 3 locations.. Since i'm assuming the
first part of the url (yourdomain.com/index.php?) is correct, the put URL
is most likely succeeding in connecting to the url, so you would need to
look at the contents of myVar to see what if anything was actually
returned.
A quick example placed in the card script.
local sKeysPushed --keys kept in this variable for the example
on rawkeydown pkey
if sKeysPushed is empty then
put pkey into sKeysPushed
else
put comma & pkey after sKeysPushed
end if
-- You would want to remove this block of course
Hi list
According to LC dictionary, the result "Returns the status of the last
command that was executed". But I had 2 unexpected experiences on my
on-rev account recently :
1- a line such as
put URL ("http://mydomain.com/index.php?"; & it) into myVar
never went through (because it was corrupte
Moreover, you'll have to start the simulator first *from Xcode*, then wait
until it fully loads, and then use the LC Test button to send your app to
the simulator. See this thread for more details:
http://forums.livecode.com/viewtopic.php?f=49&t=30592
Best,
Panos
--
On Sun, Feb 25, 2018 at 11:00
Hi Christer,
Xcode 9.3 is not supported yet (as it is still in beta). You have to
download Xcode 9.2 to use with LC 8.1.9 in MacOS Sierra or High Sierra.
Best,
Panos
--
On Sun, Feb 25, 2018 at 9:49 AM, Pyyhtiä Christer via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Any experience on
Erm . . .
I want to set up a stack that will list an end-user's keyDowns by
sending their system
a set of rawKeyUps . . .
PseudoCode:
in a button:
on mouseUp
send "rawKeyDown" to key 113
end mouseUp
in the cardScript:
on rawKeyDown XX
get keyUp XX
put XX somewhere useful
end rawKeyDow
Any experience on the set of OS/X High Sierra, with the latest update patch,
LiveCode 8.1.9 and Xcode 9.3 Beta?
Shoul I revert to Sierra and Xcode previous versions? Actually, trying to
adhere to the Apple requirement of having all apps to iPhone X, which then
requested me to load the latest X
38 matches
Mail list logo
