Re: widget properties

> 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

Re: send "keyUp" / "rawKeyUp" ?

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

hhMockup

["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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: High Sierra, LC & Xcode

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: widget properties

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 <

Re: widget properties

> 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

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: widget 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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

> 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

Re: send "keyUp" / "rawKeyUp" ?

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

send "keyUp" / "rawKeyUp" ?

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

High Sierra, LC & Xcode

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

Re: High Sierra, LC & Xcode

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=30592 Best, Panos -- On Sun, Feb 25, 2018 at 11:00

Re: High Sierra, LC & Xcode

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

Re: Question about the result

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.

Re: send "keyUp" / "rawKeyUp" ?

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

Re: widget properties

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: Question about the result

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

Re: Question about the result

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,

Re: send "keyUp" / "rawKeyUp" ?

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

Re: send "keyUp" / "rawKeyUp" ?

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

Question about the result

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

Re: widget properties

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

Re: send "keyUp" / "rawKeyUp" ?

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

Re: Question about the result

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

Re: Question about the result

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