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 properties is undefined behavior. If you want to set *all* the properties of an object to the same as another, don't do it like that, use export/import instead. Essentially my point of view is that a properties property should return all properties. Otherwise it can't really work with widgets. The manual fettling for the order of properties to set isn't really compatible with the fact that widget authors can define properties in innumerable ways that we don't know in advance, unless we force widget authors to provide the equivalent of the engine's s_preprocess_props. I just realised though that you can't set if it's a function, so it would have to be a property, and then you couldn't include the properties property :-( On Mon, Feb 26, 2018 at 3:20 AM Monte Goulding via use-livecode < use-livecode@lists.runrev.com> wrote: > > I must have misunderstood. I thought you were proposing adding all > gettable properties to the properties and not changing the way set works > (i.e. iterating all elements and setting them one at a time). > > Cheers > > Monte > ___ 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
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 sets Suggestion is to add the object state ($object) and property sets ($props) to the existing export array. Once the object state function was in place, most of the work to add other classic controls would already be done. The couple of OnLoad handlers that I’ve looked into seem to handle extra data fine since it is just ignored. It gets lost on save though. This is some of the things that came to light when vertical was added to the segmented control. This should not have any impact to this idea. On Sun, Feb 25, 2018 at 10:10 PM Brian Milby wrote: > 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 > array. > > I’ll need to look again, but I think that export uses OnSave to get the > array. Import uses OnLoad. This would save the step of setting the other > properties. > > On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> > 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 make you crazy. >> What I want are some persistent properties from "OnSave" and "OnLoad" but >> NOT the saved state of a probable buggy widget. >> >> And if I open a stack half a year later while the widget was updated, >> then I want, as it is currently, the new version without deleting and >> reinstalling all widgets of that kind (think of a stack that has a lot of >> svg-icon-widgets). >> >> >> ___ >> 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: 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 array. I’ll need to look again, but I think that export uses OnSave to get the array. Import uses OnLoad. This would save the step of setting the other properties. On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode < use-livecode@lists.runrev.com> wrote: > > 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 make you crazy. > What I want are some persistent properties from "OnSave" and "OnLoad" but > NOT the saved state of a probable buggy widget. > > And if I open a stack half a year later while the widget was updated, > then I want, as it is currently, the new version without deleting and > reinstalling all widgets of that kind (think of a stack that has a lot of > svg-icon-widgets). > > > ___ > 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: 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 use-livecode < use-livecode@lists.runrev.com> wrote: > > > > 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 sense. It would also be nice if we could somehow apply that > exported data to an existing object. > > Cheers > > Monte > ___ > 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: 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 make you crazy. What I want are some persistent properties from "OnSave" and "OnLoad" but NOT the saved state of a probable buggy widget. And if I open a stack half a year later while the widget was updated, then I want, as it is currently, the new version without deleting and reinstalling all widgets of that kind (think of a stack that has a lot of svg-icon-widgets). ___ 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
> 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 sense. It would also be nice if we could somehow apply that exported data to an existing object. Cheers Monte ___ 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
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@lists.runrev.com> wrote: > > > > On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode < > use-livecode@lists.runrev.com> 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't include all the forms of text. > > I must have misunderstood. I thought you were proposing adding all > gettable properties to the properties and not changing the way set works > (i.e. iterating all elements and setting them one at a time). > > Cheers > > Monte > ___ > 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: 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 the array to set - so just > don't include all the forms of text. I must have misunderstood. I thought you were proposing adding all gettable properties to the properties and not changing the way set works (i.e. iterating all elements and setting them one at a time). Cheers Monte ___ 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
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 Script): JavaScript is used for the lengthy transforms of the imageData and applying a few image filters. Everything else, especially the computation of the "perspective matrix" and all the display is still LC Script. You can scale, skew, translate and rotate in single or combined actions and perspective transform images up to screen size. *** The perspective transform is also used to show images in a given MOCKUP frame. There is also demo of running a gif (EM's jockey) in such mockup frames. There are still more details to explore, e.g. expanding the transform of the control polygon (and by that the image) horizontally, vertically or both. Download "hhMockup" from "Sample Stacks" (or http://livecodeshare.runrev.com/stack/867). The stack is tested to run using LC 8/9 on Mac/ Win 7+10/ Ubuntu (a few issues on linux, use latest LC 8/9 there). You can import your images and export your transformed artwork. Have fun! ___ 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: 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 | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: 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 > (htmlText, text, rtfText, styledText) then we have to have even more > complicated precedence rules than we currently do when setting. > > 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't include all the forms of text. ___ 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
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 type. > > Yes there is. If we include all the different forms of text for > example (htmlText, text, rtfText, styledText) then we have to have > even more complicated precedence rules than we currently do when > setting. FWIW, if it keeps things simpler I wouldn't change anything at all in "the properties" beyond adding the export info for widgets. Below I've copied the list of keys from getting "the properties" of a field. Neither rtfText nor even text are there, because both are permutations of the one form that covers what's needed to reproduce field contents, htmlText. Apparently a fair bit of thought went into "the properties". Unless there's a show-stopping need to alter it, I'd leave it as-is, add the widget info, and move on to other tasks. If something more complete or somehow different is needed in the future, the future would be a good time to address it. :) That is, maintain what we have, and take your time thinking through a new form of this sort of array representation of an object as that need becomes defined. As much as I appreciate the interest in this, my own needs are modest, and I know that you folks have quite a queue filled with other things. altId autoHilite autoTab backColor backPattern behavior blendLevel borderColor borderPattern borderWidth bottomColor bottomPattern cantSelect colorOverlay cursorMovement disabled dontSearch dontWrap dropShadow firstIndent fixedLineHeight focusColor focusPattern foreColor forePattern hGrid hiliteColor hilitedLines hilitePattern hScroll hScrollbar htmlText id ink innerGlow innerShadow layer layerMode listBehavior lockLoc lockText margins multipleHilites name noncontiguousHilites opaque outerGlow rect scrollbarWidth shadow shadowColor shadowOffset shadowPattern sharedText showBorder showFocusBorder showLines style tabStops textAlign textDirection textFont textHeight textSize textStyle threeD threeDHilite toggleHilites toolTip topColor topPattern traversalOn vGrid visible vScroll vScrollbar -- 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: 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 stacks + stackFiles with no scripts is significantly simpler to deal with. Either way export object covers that better. > 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 (htmlText, text, rtfText, styledText) then we have to have even more complicated precedence rules than we currently do when setting. I would suggest if we can look at all the metadata we need in the IDE about an object property and provide a way to access as much of that as possible by introspecting the object most people would be happy regardless of whether we provide an array prop to get and set it in one hit. Just about all the data is there already in the property tables. Cheers Monte ___ 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: 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 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 experiment, if you add pass rawkeydown in your second handler, does it solve the problem? Catching rawkeydown without passing it, should indeed keep anything from appearing in the field. On Sun, Feb 25, 2018 at 12:50 PM, Richmond Mathewson via use-livecode < use-livecode@lists.runrev.com> wrote: 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 so I can get them into a field? In terms of calibration all this will do is nothing as a stack that has type "q" is a script will do just that regardless of the end-user's keyboard layout. I just set my keyboard layout on my ancient iMac (10.7.5) to Bangla (Bengali), which wouldn't know a "q" to save its life. My test stack still typed a "q" into my field. I wonder what rawKeyDown and rawKeyUp the type command actually sent? I have a fantasy that goes a bit like this: Pseudocode select after field "ff" send "rawKeyUp[113]" but LiveCode "doesn't love me" that much. Richmond. On 25/2/2018 8:44 pm, Paul Dupuis via use-livecode wrote: 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 via use-livecode wrote: 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 rawKeyDown Richmond. ___ 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 ___ 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: 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 experiment, if you add pass rawkeydown in your second handler, does it solve the problem? Catching rawkeydown without passing it, should indeed keep anything from appearing in the field. On Sun, Feb 25, 2018 at 12:50 PM, Richmond Mathewson via use-livecode < use-livecode@lists.runrev.com> wrote: > 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 > so I can get them into a field? > > In terms of calibration all this will do is nothing as a stack that has > type "q" is a script will > do just that regardless of the end-user's keyboard layout. > > I just set my keyboard layout on my ancient iMac (10.7.5) to Bangla > (Bengali), which wouldn't know > a "q" to save its life. > > My test stack still typed a "q" into my field. > > I wonder what rawKeyDown and rawKeyUp the type command actually sent? > > I have a fantasy that goes a bit like this: > > Pseudocode > > select after field "ff" > send "rawKeyUp[113]" > > but LiveCode "doesn't love me" that much. > > Richmond. > > On 25/2/2018 8:44 pm, Paul Dupuis via use-livecode wrote: > >> 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 via use-livecode wrote: >> >>> 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 rawKeyDown >>> >>> Richmond. >>> ___ >>> 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 > ___ 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: 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 empty into fld "sss" put RD into fld "sss" end rawKeyDown at which point, on clicking on the button I get "113" in field "sss", and, oddly enough, empty in field "fff". Of course that doesn't help me at all as I want to do things the other way round: i.e. I want to send a rawKeyDown signal that fakes typing on the key on my keyboard that has the underlying rawKey code of 113. Richmond. On 25/2/2018 9:50 pm, Richmond Mathewson wrote: 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 so I can get them into a field? In terms of calibration all this will do is nothing as a stack that has type "q" is a script will do just that regardless of the end-user's keyboard layout. I just set my keyboard layout on my ancient iMac (10.7.5) to Bangla (Bengali), which wouldn't know a "q" to save its life. My test stack still typed a "q" into my field. I wonder what rawKeyDown and rawKeyUp the type command actually sent? I have a fantasy that goes a bit like this: Pseudocode select after field "ff" send "rawKeyUp[113]" but LiveCode "doesn't love me" that much. Richmond. On 25/2/2018 8:44 pm, Paul Dupuis via use-livecode wrote: 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 via use-livecode wrote: 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 rawKeyDown Richmond. ___ 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: 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 so I can get them into a field? In terms of calibration all this will do is nothing as a stack that has type "q" is a script will do just that regardless of the end-user's keyboard layout. I just set my keyboard layout on my ancient iMac (10.7.5) to Bangla (Bengali), which wouldn't know a "q" to save its life. My test stack still typed a "q" into my field. I wonder what rawKeyDown and rawKeyUp the type command actually sent? I have a fantasy that goes a bit like this: Pseudocode select after field "ff" send "rawKeyUp[113]" but LiveCode "doesn't love me" that much. Richmond. On 25/2/2018 8:44 pm, Paul Dupuis via use-livecode wrote: 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 via use-livecode wrote: 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 rawKeyDown Richmond. ___ 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: 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 the
same position as the "q" key on my keyboard.
Richmond.
On 25/2/2018 8:32 pm, Mike Bonner via use-livecode wrote:
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, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:
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. Mine contains
KBMODEL="pc105"
KBLAYOUT="us"
KBVARIANT=""
KBOPTIONS=""
BACKSPACE="guess"
On windows, if the system has powershell (uncertain as to versions?) you
might be able to get useful information
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("(Get-Culture).keyboardLayoutID")
This will put a number into "it" in my case, 1033.
Looking at this page.. https://www.science.co.il/lang
uage/Locale-codes.php
shows that 1033 is en_us.
Alternatively, also with powershell
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("Get--WinUserLanguageList")
At which point IT contains something like..
*LanguageTag : en-US*
*Autonym : English (United States)*
*EnglishName : English*
*LocalizedName : English (United States)*
*ScriptName : Latin script*
*InputMethodTips : {0409:0409}*
*Spellchecking : True*
*Handwriting : False*
The number for InputMethodTips means qwerty us, and is in the registry key
(for me)
The registry key: HKEY_CURRENT_USER\Keyboard Layout\Preload\1
contains the same 0409 number so perhaps queryRegister could be used to
grab that.
If the user is using a different preferred layout (overriding normal
mapping,) it might show in
HKEY_CURRENT_USER\Keyboard Layout\Substitutes\1
For example, looking at the number 00010409 denotes 409 english us
keyboard
layout overridden to be a dvorak layout.
After all this, i'm thinking that having the user do a nice keyboard
faceroll might still be the easiest solution.
On Sun, Feb 25, 2018 at 9:26 AM, Mike Bonner wrote:
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 access to a mac.
Unsure about how to go about it on windows.
For example, on my system one of the first lines contains qwerty as part
of the line. The only issue with this, is that custom mapings are
possible, though it looks like the aliases are part of the information.
I've seen operating systems do the "press the key to the right of the
left
shift key.." sequence to determine base layout (which again, wouldn't
cover
every base if the user has changed the keyboard map, so you might need to
have them press every key... xkbcom might get around that if you can
figure out enough to interpret the results)
On Sun, Feb 25, 2018 at 8:22 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:
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-user Farhad, and Iranian who uses an
Iranian keyboard layout
(something I don't know), and let's call our me Richmond owing to a
slight lack of imagination
on my part; and I use a US English keyboard layout, which I know, but
isn't useful information
under the circumstances.
Now if I click on the key that yields a rawKey of 113 I get a "q".
If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق
And I am unable to type close-quotes there.
So I should like to find a way to fake someone pressing down on a key on
their home-computer
to see what the keyUp result is.
Now I realise I cannot SEND a command telling the key on the keyboard to
do
"a pianola" and depress itself (wouldn't that be fun?).
It would, however, be groovy if one could work out Farhad's keys without
having him to
go "bash, bash" all the way along the rows of his keyboard.
Richmond.
On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote:
A quick example placed in the card
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 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: 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 via use-livecode wrote: > 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 rawKeyDown > > Richmond. > ___ > 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: 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 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 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. Mine contains
>> KBMODEL="pc105"
>> KBLAYOUT="us"
>> KBVARIANT=""
>> KBOPTIONS=""
>> BACKSPACE="guess"
>>
>> On windows, if the system has powershell (uncertain as to versions?) you
>> might be able to get useful information
>>
>> set the hideconsolewindows to true
>> set the shellcommand to "powershell"
>> get shell("(Get-Culture).keyboardLayoutID")
>>
>> This will put a number into "it" in my case, 1033.
>> Looking at this page.. https://www.science.co.il/lang
>> uage/Locale-codes.php
>> shows that 1033 is en_us.
>>
>> Alternatively, also with powershell
>>
>> set the hideconsolewindows to true
>> set the shellcommand to "powershell"
>> get shell("Get--WinUserLanguageList")
>>
>> At which point IT contains something like..
>> *LanguageTag : en-US*
>> *Autonym : English (United States)*
>> *EnglishName : English*
>> *LocalizedName : English (United States)*
>> *ScriptName : Latin script*
>> *InputMethodTips : {0409:0409}*
>> *Spellchecking : True*
>> *Handwriting : False*
>>
>>
>> The number for InputMethodTips means qwerty us, and is in the registry key
>> (for me)
>> The registry key: HKEY_CURRENT_USER\Keyboard Layout\Preload\1
>> contains the same 0409 number so perhaps queryRegister could be used to
>> grab that.
>>
>> If the user is using a different preferred layout (overriding normal
>> mapping,) it might show in
>> HKEY_CURRENT_USER\Keyboard Layout\Substitutes\1
>> For example, looking at the number 00010409 denotes 409 english us
>> keyboard
>> layout overridden to be a dvorak layout.
>>
>> After all this, i'm thinking that having the user do a nice keyboard
>> faceroll might still be the easiest solution.
>>
>> On Sun, Feb 25, 2018 at 9:26 AM, Mike Bonner wrote:
>>
>> 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 access to a mac.
>>> Unsure about how to go about it on windows.
>>>
>>> For example, on my system one of the first lines contains qwerty as part
>>> of the line. The only issue with this, is that custom mapings are
>>> possible, though it looks like the aliases are part of the information.
>>>
>>> I've seen operating systems do the "press the key to the right of the
>>> left
>>> shift key.." sequence to determine base layout (which again, wouldn't
>>> cover
>>> every base if the user has changed the keyboard map, so you might need to
>>> have them press every key... xkbcom might get around that if you can
>>> figure out enough to interpret the results)
>>>
>>>
>>>
>>> On Sun, Feb 25, 2018 at 8:22 AM, Richmond Mathewson via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> 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-user Farhad, and Iranian who uses an
Iranian keyboard layout
(something I don't know), and let's call our me Richmond owing to a
slight lack of imagination
on my part; and I use a US English keyboard layout, which I know, but
isn't useful information
under the circumstances.
Now if I click on the key that yields a rawKey of 113 I get a "q".
If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق
And I am unable to type close-quotes there.
So I should like to find a way to fake someone pressing down on a key on
their home-computer
to see what the keyUp result is.
Now I realise I cannot SEND a command telling the key on the keyboard to
do
"a pianola" and depress itself (wouldn't that be fun?).
It would, however, be groovy if one could work out Farhad's keys without
having him to
go "bash, bash" all the way along the rows of his keyboard.
Richmond.
On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote:
>>>
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 it. Mine contains
KBMODEL="pc105"
KBLAYOUT="us"
KBVARIANT=""
KBOPTIONS=""
BACKSPACE="guess"
On windows, if the system has powershell (uncertain as to versions?) you
might be able to get useful information
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("(Get-Culture).keyboardLayoutID")
This will put a number into "it" in my case, 1033.
Looking at this page.. https://www.science.co.il/language/Locale-codes.php
shows that 1033 is en_us.
Alternatively, also with powershell
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("Get--WinUserLanguageList")
At which point IT contains something like..
*LanguageTag : en-US*
*Autonym : English (United States)*
*EnglishName : English*
*LocalizedName : English (United States)*
*ScriptName : Latin script*
*InputMethodTips : {0409:0409}*
*Spellchecking : True*
*Handwriting : False*
The number for InputMethodTips means qwerty us, and is in the registry key
(for me)
The registry key: HKEY_CURRENT_USER\Keyboard Layout\Preload\1
contains the same 0409 number so perhaps queryRegister could be used to
grab that.
If the user is using a different preferred layout (overriding normal
mapping,) it might show in
HKEY_CURRENT_USER\Keyboard Layout\Substitutes\1
For example, looking at the number 00010409 denotes 409 english us keyboard
layout overridden to be a dvorak layout.
After all this, i'm thinking that having the user do a nice keyboard
faceroll might still be the easiest solution.
On Sun, Feb 25, 2018 at 9:26 AM, Mike Bonner wrote:
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 access to a mac.
Unsure about how to go about it on windows.
For example, on my system one of the first lines contains qwerty as part
of the line. The only issue with this, is that custom mapings are
possible, though it looks like the aliases are part of the information.
I've seen operating systems do the "press the key to the right of the left
shift key.." sequence to determine base layout (which again, wouldn't cover
every base if the user has changed the keyboard map, so you might need to
have them press every key... xkbcom might get around that if you can
figure out enough to interpret the results)
On Sun, Feb 25, 2018 at 8:22 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:
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-user Farhad, and Iranian who uses an
Iranian keyboard layout
(something I don't know), and let's call our me Richmond owing to a
slight lack of imagination
on my part; and I use a US English keyboard layout, which I know, but
isn't useful information
under the circumstances.
Now if I click on the key that yields a rawKey of 113 I get a "q".
If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق
And I am unable to type close-quotes there.
So I should like to find a way to fake someone pressing down on a key on
their home-computer
to see what the keyUp result is.
Now I realise I cannot SEND a command telling the key on the keyboard to
do
"a pianola" and depress itself (wouldn't that be fun?).
It would, however, be groovy if one could work out Farhad's keys without
having him to
go "bash, bash" all the way along the rows of his keyboard.
Richmond.
On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote:
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, but for testing
-- it lets you push the shift key to see whats been captured
if the shiftkey is down then
put sKeysPushed
end if
pass rawkeydown --pass the key
end rawkeydown
I know it was just pseudocode, but as far as I know you can't "send" a
message to a key so..
If you want to be able to click a button to send a rawkeydown (rather
than
just typing them) you could use something like:
on mouseup
send "rawkeydown 110" to this card
end mouseup
or
on mouseup
displatch "rawkeydow
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 powershell (uncertain as to versions?) you
might be able to get useful information
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("(Get-Culture).keyboardLayoutID")
This will put a number into "it" in my case, 1033.
Looking at this page.. https://www.science.co.il/language/Locale-codes.php
shows that 1033 is en_us.
Alternatively, also with powershell
set the hideconsolewindows to true
set the shellcommand to "powershell"
get shell("Get--WinUserLanguageList")
At which point IT contains something like..
*LanguageTag : en-US*
*Autonym : English (United States)*
*EnglishName : English*
*LocalizedName : English (United States)*
*ScriptName : Latin script*
*InputMethodTips : {0409:0409}*
*Spellchecking : True*
*Handwriting : False*
The number for InputMethodTips means qwerty us, and is in the registry key
(for me)
The registry key: HKEY_CURRENT_USER\Keyboard Layout\Preload\1
contains the same 0409 number so perhaps queryRegister could be used to
grab that.
If the user is using a different preferred layout (overriding normal
mapping,) it might show in
HKEY_CURRENT_USER\Keyboard Layout\Substitutes\1
For example, looking at the number 00010409 denotes 409 english us keyboard
layout overridden to be a dvorak layout.
After all this, i'm thinking that having the user do a nice keyboard
faceroll might still be the easiest solution.
On Sun, Feb 25, 2018 at 9:26 AM, Mike Bonner wrote:
> 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 access to a mac.
> Unsure about how to go about it on windows.
>
> For example, on my system one of the first lines contains qwerty as part
> of the line. The only issue with this, is that custom mapings are
> possible, though it looks like the aliases are part of the information.
>
> I've seen operating systems do the "press the key to the right of the left
> shift key.." sequence to determine base layout (which again, wouldn't cover
> every base if the user has changed the keyboard map, so you might need to
> have them press every key... xkbcom might get around that if you can
> figure out enough to interpret the results)
>
>
>
> On Sun, Feb 25, 2018 at 8:22 AM, Richmond Mathewson via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> 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-user Farhad, and Iranian who uses an
>> Iranian keyboard layout
>> (something I don't know), and let's call our me Richmond owing to a
>> slight lack of imagination
>> on my part; and I use a US English keyboard layout, which I know, but
>> isn't useful information
>> under the circumstances.
>>
>> Now if I click on the key that yields a rawKey of 113 I get a "q".
>>
>> If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق
>>
>> And I am unable to type close-quotes there.
>>
>> So I should like to find a way to fake someone pressing down on a key on
>> their home-computer
>> to see what the keyUp result is.
>>
>> Now I realise I cannot SEND a command telling the key on the keyboard to
>> do
>> "a pianola" and depress itself (wouldn't that be fun?).
>>
>> It would, however, be groovy if one could work out Farhad's keys without
>> having him to
>> go "bash, bash" all the way along the rows of his keyboard.
>>
>> Richmond.
>>
>>
>>
>> On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote:
>>
>>> 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, but for testing
>>> -- it lets you push the shift key to see whats been captured
>>> if the shiftkey is down then
>>>put sKeysPushed
>>> end if
>>>
>>> pass rawkeydown --pass the key
>>>
>>> end rawkeydown
>>>
>>> I know it was just pseudocode, but as far as I know you can't "send" a
>>> message to a key so..
>>> If you want to be able to click a button to send a rawkeydown (rather
>>> than
>>> just typing them) you could use something like:
>>>
>>>
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 why export to tVar > would be useful to extend to all objects. Whether we use what we've been using for all types, or add all types to the newer currently-widget-specific syntax, is fine by me. It's encouraging that you share an interest in this. Whatever syntax you prefer would be fine by me. >> > It is not correct to say that the properties property is used to >> > create the property inspector >> >> I don't know anyone who said that. But imagine how much simpler it >> would be to make an Inspector if "the properties" were completed to >> handle this new class of objects. >> > You did, in your earlier email ;-) If I did say that it does rather than that it could, I'll trust your memory on that. I have been prone to optimism. In the conversation we're having I didn't, because I've recently poked around in the IDE enough to have a sense of how the Inspector works. Chipp, Geoff, Ken, Pete, I, and others use "the properties" for our respective prop viewing/editing tools. This may be why revNavigator's prop sheet doesn't support widgets; Chipp's doesn't either, and discovering that my own doesn't is what prompted this thread. > Unless you meant 'the properties' abstractly. If that's the case then > there is such a function - it is in the IDE library and the IDE does > use it on all object types to generate the property inspector. Yes, as I wrote to hh yesterday this isn't a show-stopper by any means. LC is a very flexible language, and there's little we can't script. My request here to treat widgets like first-class objects using the same long-standing mechanism we enjoy for all other objects is more akin to the recent extension of the "files" and "folders" functions: It never killed any of us to have to write our own custom functions to get the working directory, change to the one we're interested in, get the files/folders, and restore the working directory to what it was, and then return the list. But it's oh so very convenient to have that functionality built into the engine now. Same with obtaining a prop array: those of us who make good use of "the properties" won't fall over dead if we have to add additional code to support one newer object class. It would just be oh so very convenient to have that built into the engine. If it were, all tools and libraries written to use "the properties" would work for widgets as well. As it is, widgets are unsupported by all of them, until every author gets around to adding the additional code needed for that one object type. For those invested in promoting widget adoption, the choice would seem clear. > I'm not trying to argue that we shouldn't extend the properties > property - actually efficiency may indeed be one of the best reasons > in terms of being able to set a bunch of properties in one go. I'm > just trying to gather information to figure out the priority of such > a thing. Your interest is much appreciated. >> I'm familiar with the existing mechanisms, but help me understand: >> which scriptable properties would a widget have which would not be of >> interest to a scripter? > > I didn't say they aren't of interest to the scripter, I said you might > not want to present them in a property inspector. And it's not just > widgets, all objects have properties that are not really relevant to > the property inspector. Most obviously, the properties property. Of course (though it does conjure amusing ideas of recursion; "It's properties all the way down" ). And the script property as well, handled separately given its special role. I'm fine with continuing that. > Others are, for example, the noncontiguousHilites of a standard text > field, or the menuHistory of a default button. Many widgets have other > properties that overlap, for example the itemArray of the navigation > bar, which overlaps with (in fact subsumes) the itemLabels, itemIcons, > itemSelectedIcons etc. Thank you, those are very good examples. The completeness of "the properties" does not oblige any toolmaker to present information in ways that aren't useful. > Again, I am not arguing that there shouldn't be a properties property > extended to widgets. I see that efficiency and property sheets are > reasonable use-cases for it. The trick is to ensure that the VCS > use-case can be extricated. 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. > > I wonder if the properties of should actually be a function, to > avoid there always being a property that (for obvious reasons) ca
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, 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 404 type or other type errors were returned as part of the headers.
> >
>
> Actually, when I wrote "never went through", that's exactly what happened :
> the request never went through, the server never received that request and
> therefore never returned anything. And even more surprising, the line
>put URL ("http://mydomain.com/index.php?"; & it) into myVar
> didn't block the execution of the script and the following lines were
> executed,
> and myVar was empty.
>
> That's the reason why I was surprised to see that the result was empty as
> well;
> I would expect something like "data corrupted" or "impossible to send
> request"...
> And also to have the script blocked by that line...
>
>
>
> ___
> 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: 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 404 type or other type errors were returned as part of the headers.
>
Actually, when I wrote "never went through", that's exactly what happened :
the request never went through, the server never received that request and
therefore never returned anything. And even more surprising, the line
put URL ("http://mydomain.com/index.php?"; & it) into myVar
didn't block the execution of the script and the following lines were
executed,
and myVar was empty.
That's the reason why I was surprised to see that the result was empty as
well;
I would expect something like "data corrupted" or "impossible to send
request"...
And also to have the script blocked by that line...
___
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: 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 other part, if anyone can educate me.. Why doesn't
revzipopenarchive work from the message box (at all) but works fine in a
script. Rather frustrating to test something in the msg box and have it
misbehave simply because its coming from the msg box.
On Sun, Feb 25, 2018 at 8:26 AM, jbv via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 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 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. In a case where the url is actually able to be hit, 'the
> > result' will be empty, but the value returned from the server may be
> > invalid data. It still wouldn't hurt to look at "it" also, IIRC sometimes
> > useful info will appear there. (though in this case, my guess is that
> > garbled info is in myVar) Of course, if the url is invalid, then the
> > result should tell you so.
> >
> > As for the second.. If I test from the message box, revzipopenarchive
> > seems to do pretty much.. um.. Nothing. Doesn't open an archive, doesn't
> > return an error message.. Nothing in it, or the result.. Weird. So I put
> > code in a button and things behaved as expected. (when specifying a path
> > with no permissions, the result told me so. Same with an invalid path.
> > (this is
> > on 9 dp 11)
> >
> > No clue why it won't work from the message box, or if its related to what
> > happened on your end.
> >
> > On Sun, Feb 25, 2018 at 6:50 AM, jbv via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> 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 corrupted : contained some extra characters such
> >> as ascii 10), however the result remained empty.
> >>
> >> 2- when trying to create a zip archive
> >> revZipOpenArchive "home/myaccount/public_html/dir1/dir2/dir3", "write"
> >> the name of directory "dir2" had been changed and therefore "dir3"
> >> could not be found; however the result remained empty.
> >>
> >> I know that in the 2nd case I could use the sysError function, but
> >> according to the doc, the result shouldn't be empty anyway... So my
> >> question : am I expecting too much from the result, like containing some
> >> useful error message every time something doesn't work as expected ?
> >>
> >> Thanks in advance.
> >> jbv
> >>
> >>
> >> ___
> >> 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
>
___
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: 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 access to a mac. Unsure about how to go about it on windows. For example, on my system one of the first lines contains qwerty as part of the line. The only issue with this, is that custom mapings are possible, though it looks like the aliases are part of the information. I've seen operating systems do the "press the key to the right of the left shift key.." sequence to determine base layout (which again, wouldn't cover every base if the user has changed the keyboard map, so you might need to have them press every key... xkbcom might get around that if you can figure out enough to interpret the results) On Sun, Feb 25, 2018 at 8:22 AM, Richmond Mathewson via use-livecode < use-livecode@lists.runrev.com> wrote: > 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-user Farhad, and Iranian who uses an > Iranian keyboard layout > (something I don't know), and let's call our me Richmond owing to a slight > lack of imagination > on my part; and I use a US English keyboard layout, which I know, but > isn't useful information > under the circumstances. > > Now if I click on the key that yields a rawKey of 113 I get a "q". > > If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق > > And I am unable to type close-quotes there. > > So I should like to find a way to fake someone pressing down on a key on > their home-computer > to see what the keyUp result is. > > Now I realise I cannot SEND a command telling the key on the keyboard to do > "a pianola" and depress itself (wouldn't that be fun?). > > It would, however, be groovy if one could work out Farhad's keys without > having him to > go "bash, bash" all the way along the rows of his keyboard. > > Richmond. > > > > On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote: > >> 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, but for testing >> -- it lets you push the shift key to see whats been captured >> if the shiftkey is down then >>put sKeysPushed >> end if >> >> pass rawkeydown --pass the key >> >> end rawkeydown >> >> I know it was just pseudocode, but as far as I know you can't "send" a >> message to a key so.. >> If you want to be able to click a button to send a rawkeydown (rather than >> just typing them) you could use something like: >> >> on mouseup >> send "rawkeydown 110" to this card >> end mouseup >> >> or >> on mouseup >> displatch "rawkeydown" with (any item of "119,240,43") --> random keys to send >> end mouseup >> >> Now.. If you need to track keypresses while NOT actively using your >> application, it requires a different method. You'd need to use a >> different >> method. You would need to use a send loop and check the keysdown and >> build >> up your keys list that way. Using this method would be problematic >> though, >> for example.. A user holds a key down long enough for several loops to >> happen, so the keysdown would show the key multiple times. Which might be >> appropriate if autorepeat is being used, but then you have no idea how >> many >> "repeats" there were because its based on the repeat rate. It would be >> very difficult to have much accuracy using this method. (easiest might be >> to check current keysdown against previous keysdown and only log if there >> is a difference, then use your own noggin to realize that litle is little) >> >> >> On Sun, Feb 25, 2018 at 3:09 AM, Richmond Mathewson via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> 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 rawKeyDown >>> >>> Richmond. >>> ___ >>> 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
> > 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 properties" as a > universal representation of object props back around '00 was for the > rapid things we can do for new object creation. > > As an array, the value lends itself particularly well for a wide range > of needs. > > 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 why export to tVar would be useful to extend to all objects. > Another would be transferable styles. I can make a button or field how > I like it, and then store only the things I care about to represent that > "style". Later I can union that subset with "the properties" of another > object of that type and have them applied in one simple and highly > efficient move. > > There may be other reasons this was requested as a universal way of > representing object properties. That's just the short list of things > that come to mind off the top of my head right now. > > > It is not correct to say that the properties property is used to > > create the property inspector > > I don't know anyone who said that. But imagine how much simpler it > would be to make an Inspector if "the properties" were completed to > handle this new class of objects. > > You did, in your earlier email ;-) > Consider the LC IDE's Inspector: to populate its controls it obtains > "the properties" from all LC-native objects, and "the properties" + > widget-specific info from widgets. In fact, add that to the use-case list above. > > Having one universal means of getting and setting object properties en > masse is very helpful. > Unless you meant 'the properties' abstractly. If that's the case then there is such a function - it is in the IDE library and the IDE does use it on all object types to generate the property inspector. > And we've had it for more than a decade and a half. > > And we have it still, except for one new class of objects, widgets. > > If we extend this mechanism to include the data the engine already knows > about properties, widgets will be elevated to first class objects like > anything else. > > Isn't having widgets behave more like engine-native controls the reason > we use them over compound groups? > > I'm not trying to argue that we shouldn't extend the properties property - actually efficiency may indeed be one of the best reasons in terms of being able to set a bunch of properties in one go. I'm just trying to gather information to figure out the priority of such a thing. > >- that is in fact done from property definition files. There are things > > that are properties that you might not want to present in a property > > inspector, and there are things that you might want to present in the > > property inspector that are not strictly properties. Hence we maintain > > these lists: > > > > https://github.com/livecode/livecode-ide/tree/develop/Toolset/resources/supporting_files/property_definitions > > I'm familiar with the existing mechanisms, but help me understand: which > scriptable properties would a widget have which would not be of interest > to a scripter? > I didn't say they aren't of interest to the scripter, I said you might not want to present them in a property inspector. And it's not just widgets, all objects have properties that are not really relevant to the property inspector. Most obviously, the properties property. Others are, for example, the noncontiguousHilites of a standard text field, or the menuHistory of a default button. Many widgets have other properties that overlap, for example the itemArray of the navigation bar, which overlaps with (in fact subsumes) the itemLabels, itemIcons, itemSelectedIcons etc. See the navigation bar's itemArray editor in the PI - in my view this is much nicer than a set of fields. Another type would be transient properties of mobile native objects - eg the 'focused' property of the android native field which is not saved with the object. It is completely unuseful to set this property via PI in the IDE, but still needs to be a property so you can set it from script. As the existence of such properties is subject to the whims of the widget author, they could crop up anywhere, hence the desire to make the ones that *should* show up part of the metadata. > > Because the 'classic controls' are somewhat multipurpose, the notion > > of control type isn't fine-grained enough to use the properties > > property for a good property inspector. > > Agreed. Another good argument for a property sheet, but that's for > another thread. > I don't understand how that's an argument
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 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. In a case where the url is actually able to be hit, 'the
> result' will be empty, but the value returned from the server may be
> invalid data. It still wouldn't hurt to look at "it" also, IIRC sometimes
> useful info will appear there. (though in this case, my guess is that
> garbled info is in myVar) Of course, if the url is invalid, then the
> result should tell you so.
>
> As for the second.. If I test from the message box, revzipopenarchive
> seems to do pretty much.. um.. Nothing. Doesn't open an archive, doesn't
> return an error message.. Nothing in it, or the result.. Weird. So I put
> code in a button and things behaved as expected. (when specifying a path
> with no permissions, the result told me so. Same with an invalid path.
> (this is
> on 9 dp 11)
>
> No clue why it won't work from the message box, or if its related to what
> happened on your end.
>
> On Sun, Feb 25, 2018 at 6:50 AM, jbv via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> 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 corrupted : contained some extra characters such
>> as ascii 10), however the result remained empty.
>>
>> 2- when trying to create a zip archive
>> revZipOpenArchive "home/myaccount/public_html/dir1/dir2/dir3", "write"
>> the name of directory "dir2" had been changed and therefore "dir3"
>> could not be found; however the result remained empty.
>>
>> I know that in the 2nd case I could use the sysError function, but
>> according to the doc, the result shouldn't be empty anyway... So my
>> question : am I expecting too much from the result, like containing some
>> useful error message every time something doesn't work as expected ?
>>
>> Thanks in advance.
>> jbv
>>
>>
>> ___
>> 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: 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 end-user Farhad, and Iranian who uses an Iranian keyboard layout (something I don't know), and let's call our me Richmond owing to a slight lack of imagination on my part; and I use a US English keyboard layout, which I know, but isn't useful information under the circumstances. Now if I click on the key that yields a rawKey of 113 I get a "q". If Farhad clicks on the key that yields a rawKey of 113 he gets a "ق And I am unable to type close-quotes there. So I should like to find a way to fake someone pressing down on a key on their home-computer to see what the keyUp result is. Now I realise I cannot SEND a command telling the key on the keyboard to do "a pianola" and depress itself (wouldn't that be fun?). It would, however, be groovy if one could work out Farhad's keys without having him to go "bash, bash" all the way along the rows of his keyboard. Richmond. On 25/2/2018 4:13 pm, Mike Bonner via use-livecode wrote: 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, but for testing -- it lets you push the shift key to see whats been captured if the shiftkey is down then put sKeysPushed end if pass rawkeydown --pass the key end rawkeydown I know it was just pseudocode, but as far as I know you can't "send" a message to a key so.. If you want to be able to click a button to send a rawkeydown (rather than just typing them) you could use something like: on mouseup send "rawkeydown 110" to this card end mouseup or on mouseup displatch "rawkeydown" with (any item of "119,240,43") -- wrote: 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 rawKeyDown Richmond. ___ 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: 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. In a case where the url is actually able to be hit, 'the result'
will be empty, but the value returned from the server may be invalid data.
It still wouldn't hurt to look at "it" also, IIRC sometimes useful info
will appear there. (though in this case, my guess is that garbled info is
in myVar) Of course, if the url is invalid, then the result should tell
you so.
As for the second.. If I test from the message box, revzipopenarchive seems
to do pretty much.. um.. Nothing. Doesn't open an archive, doesn't return
an error message.. Nothing in it, or the result.. Weird. So I put code in
a button and things behaved as expected. (when specifying a path with no
permissions, the result told me so. Same with an invalid path. (this is
on 9 dp 11)
No clue why it won't work from the message box, or if its related to what
happened on your end.
On Sun, Feb 25, 2018 at 6:50 AM, jbv via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 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 corrupted : contained some extra
> characters such as ascii 10), however the result remained empty.
>
> 2- when trying to create a zip archive
>revZipOpenArchive "home/myaccount/public_html/dir1/dir2/dir3", "write"
> the name of directory "dir2" had been changed and therefore "dir3" could
> not be found; however the result remained empty.
>
> I know that in the 2nd case I could use the sysError function, but
> according to the doc, the result shouldn't be empty anyway...
> So my question : am I expecting too much from the result, like containing
> some useful error message every time something doesn't work as expected ?
>
> Thanks in advance.
> jbv
>
>
> ___
> 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: 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 course, but for testing -- it lets you push the shift key to see whats been captured if the shiftkey is down then put sKeysPushed end if pass rawkeydown --pass the key end rawkeydown I know it was just pseudocode, but as far as I know you can't "send" a message to a key so.. If you want to be able to click a button to send a rawkeydown (rather than just typing them) you could use something like: on mouseup send "rawkeydown 110" to this card end mouseup or on mouseup displatch "rawkeydown" with (any item of "119,240,43") -- wrote: > 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 rawKeyDown > > Richmond. > ___ > 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
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 corrupted : contained some extra
characters such as ascii 10), however the result remained empty.
2- when trying to create a zip archive
revZipOpenArchive "home/myaccount/public_html/dir1/dir2/dir3", "write"
the name of directory "dir2" had been changed and therefore "dir3" could
not be found; however the result remained empty.
I know that in the 2nd case I could use the sysError function, but
according to the doc, the result shouldn't be empty anyway...
So my question : am I expecting too much from the result, like containing
some useful error message every time something doesn't work as expected ?
Thanks in advance.
jbv
___
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: 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&t=30592 Best, Panos -- On Sun, Feb 25, 2018 at 11:00 AM, panagiotis merakos wrote: > 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 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 Xcode. >> >> With my 2010 MacBook Pro (High Sierra, LC 8.1.9, Xcode 9.3 Beta), with >> 8GB the simulator start takes well over 10 minutes - haven't bee able to >> get the test app to load into the simulator, yet. >> >> Still being fresh to iOS deployment, with a fully operational and tested >> app on Android devices, I just cannot find out a good guide whaat exact >> steps to take to get the process done. For example, do I have to load >> Xcode before trying to start the simulation from LC? How exactly should I >> do the app property provisioning; should I first define the app in Xcode >> (it let me try to create app related password, then spitted out its own, >> neither works to let me log in...)? >> >> Loading has now taken more than 20 minutes...the line clock still >> rotates... >> >> Christer Pyyhtiä >> MindCrea Ltd >> 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
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 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 Xcode. > > With my 2010 MacBook Pro (High Sierra, LC 8.1.9, Xcode 9.3 Beta), with 8GB > the simulator start takes well over 10 minutes - haven't bee able to get > the test app to load into the simulator, yet. > > Still being fresh to iOS deployment, with a fully operational and tested > app on Android devices, I just cannot find out a good guide whaat exact > steps to take to get the process done. For example, do I have to load > Xcode before trying to start the simulation from LC? How exactly should I > do the app property provisioning; should I first define the app in Xcode > (it let me try to create app related password, then spitted out its own, > neither works to let me log in...)? > > Loading has now taken more than 20 minutes...the line clock still > rotates... > > Christer Pyyhtiä > MindCrea Ltd > 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
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 rawKeyDown Richmond. ___ 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
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 Xcode. With my 2010 MacBook Pro (High Sierra, LC 8.1.9, Xcode 9.3 Beta), with 8GB the simulator start takes well over 10 minutes - haven't bee able to get the test app to load into the simulator, yet. Still being fresh to iOS deployment, with a fully operational and tested app on Android devices, I just cannot find out a good guide whaat exact steps to take to get the process done. For example, do I have to load Xcode before trying to start the simulation from LC? How exactly should I do the app property provisioning; should I first define the app in Xcode (it let me try to create app related password, then spitted out its own, neither works to let me log in...)? Loading has now taken more than 20 minutes...the line clock still rotates... Christer Pyyhtiä MindCrea Ltd 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
