Re: variable xref

[Mike Kerner via use-livecode]

I don't want to pretend to be an expert on the topic of writing compilers,
since I only ever wrote two, both under the watchful obsession of a
professor, and my lex and parse code were not optimal in either case.  In
general, they were some of the easiest pieces of large code I ever wrote
because the grammars were so rigid and rule-based.  Building forgiveness
into them would have made the poor developer's life easier, even thought
that meant adding a third pass to try to ascertain context instead of
blindly aborting when something didn't exactly fit the formula.

I agree that unquoted literals are not ideal.  I think they should be
deprecated, and I think they should have been removed in 1986, so add that
to the LC10 list.  They have always made reading scripts more difficult.
Readability and approachability are two things that have set xtalk apart.
Unquoted literals detract from that.
___
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: OSX printing of images issue

[Mark Talluto via use-livecode]

I will ask one of my co-workers to get in contact with you tomorrow. She writes 
printing code all the time. 

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 


> On Mar 29, 2018, at 12:33 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> Still asking if anyone has run into to something like this under OSX?
> Has anyone run into issue where you are trying to print or export a card
> whil it is off screen or invisible and not have it render properly? Any
> known tricks to get LiveCode to force a render of a card's objects if it
> is off screen or invisible?

___
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: Blurring field contents

[scott--- via use-livecode]

If blurring turns out to be too problematic you might consider just replacing 
text with bullets or Lorem Ipsum.

--
Scott Morrow


> On Mar 29, 2018, at 1:41 PM, David V Glasgow via use-livecode 
>  wrote:
> 
> 
> 
>> On 29 Mar 2018, at 5:44 pm, Paul Hibbert via use-livecode 
>>  wrote:
>> 
>> That tutorial is a bit outdated now that there is a “blur” command, 
>> introduced in LC 8.0, it’s quicker and easier to use.
>> 
>> Paul
>> 
> 
> Ah! Thank you, Paul.  That’s good to know.  I am a bit Richmondesque in my 
> attachment to older versions of LC, so I have only played a little with LC 8 
> 
> To those asking why I would want to do this, the answer is to hide clinically 
> sensitive information whilst making it clear that the field is completed.  It 
> means that clinicians can generate an anonymised snapshot of the screen to 
> use in presentations/clinical supervision.  Its a technique routinely used in 
> walkthroughs or screencasts of clinical information displayed on screen.  
> There was a rather nice implementation in the ScreenSteps app from Blue Mango 
> .
> 
> Thanks and best wishes,
> 
> David G
> ___
> 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: Livecode Json Arrays Key Sort

[Brian Milby via use-livecode]

The fix is probably as easy as exposing the list type to LCS. Mark
mentioned that at the last LCG last year. Since the parser already uses the
list type and the engine has a list type internally it shouldn’t be that
hard.
On Thu, Mar 29, 2018 at 5:34 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 03/29/2018 01:25 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> > put JSONToArray(tJson) into sColArrayA
> >
> >
> >
> > It is my imagination:
> >
> >
> >
> > Or  are the keys of {object set} output as hash order (as per
> dictionary, required sort them first)
> >
>
> https://quality.livecode.com/show_bug.cgi?id=19698
> ...maybe it's worth prodding Mark Waddingham (comment #10) that *now*
> would be a good time to fix this.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: Livecode Json Arrays Key Sort

[Mark Wieder via use-livecode]

On 03/29/2018 01:25 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

put JSONToArray(tJson) into sColArrayA



It is my imagination:



Or  are the keys of {object set} output as hash order (as per dictionary, 
required sort them first)



https://quality.livecode.com/show_bug.cgi?id=19698
...maybe it's worth prodding Mark Waddingham (comment #10) that *now* 
would be a good time to fix this.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Blurring field contents

[David V Glasgow via use-livecode]

> On 29 Mar 2018, at 5:44 pm, Paul Hibbert via use-livecode 
>  wrote:
> 
> That tutorial is a bit outdated now that there is a “blur” command, 
> introduced in LC 8.0, it’s quicker and easier to use.
> 
> Paul
> 

Ah! Thank you, Paul.  That’s good to know.  I am a bit Richmondesque in my 
attachment to older versions of LC, so I have only played a little with LC 8 

To those asking why I would want to do this, the answer is to hide clinically 
sensitive information whilst making it clear that the field is completed.  It 
means that clinicians can generate an anonymised snapshot of the screen to use 
in presentations/clinical supervision.  Its a technique routinely used in 
walkthroughs or screencasts of clinical information displayed on screen.  There 
was a rather nice implementation in the ScreenSteps app from Blue Mango .

Thanks and best wishes,

David G
___
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

Livecode Json Arrays Key Sort

[Sannyasin Brahmanathaswami via use-livecode]

put JSONToArray(tJson) into sColArrayA



It is my imagination:



Or  are the keys of {object set} output as hash order (as per dictionary, 
required sort them first)

simply delimited by



{

1

3

5

6

7

2

4

}



but keys of an array output as numeric



[{

1

2

3

4

]]



get always



1

2

3

4



with sorting?






___
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: How to handle BasicAuth in Browser widget?

[Bob Sneidar via use-livecode]

I vote for #2

Bob S


> On Mar 28, 2018, at 16:21 , Monte Goulding via use-livecode 
>  wrote:
> 
> I think we would either need to add support for a callback or present a 
> dialog natively. 


___
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: OSX printing of images issue

[Paul Dupuis via use-livecode]

On 3/28/2018 11:28 AM, Paul Dupuis via use-livecode wrote:
> I have a print subsystem for my application that prints a particular set
> of data by laying our the page (sizing the card to the paper, allowing
> for margins, etc, where the content area of the page is a single image
> object. The resizeQuality is set to "best" and alwaysBuffer is true
>
> When I print under Windows (8.x or 10) to a real printer or to PDF, the
> result appears as expected.
>
> When I print under OSX (10.9.5 and up) some of the images are messed up:
> Some are squished to a vertical bar a few pixels wide. Some are the
> right size but are just a big rectangle of black and color stripes. Some
> print properly. This happens whether to Preview PDF or to a real printer.
>
> This occurs under LC8.1.9 (and all the way back to at least LC 6.7.11)
>
> I have stepped through my print system in the debugger and each page
> appears exactly as it should (correctly layed out with a good looking
> image) before the "print card" command.
>
> Has anyone experienced this and have any ideas for a work-around or a fix?
 
I added some code to try to capture/create a test stack to report this
as a bug. Before I start my "page" repeat loop, I create invisible stack
"savePrinting" and set the rect of it to the rect of my print stack
(already set to the paper size)
During the repeat loop, just before I execute "print card", I copy this
card to stack "savePrinting".
And after the repeat loop, I save the savePrinting stack to the desktop
and delete it.

Now with this debug code in place, printing under OSX work fine. It is
as it the command 'copy this card to stack "savePrinting" ' forces the
objects on the card to be rendered properly when the 'print card' (the
next statement) is executed.

Still asking if anyone has run into to something like this under OSX?
Has anyone run into issue where you are trying to print or export a card
whil it is off screen or invisible and not have it render properly? Any
known tricks to get LiveCode to force a render of a card's objects if it
is off screen or invisible?


___
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: Blurring field contents

[Rick Harrison via use-livecode]

Why do you want to blur text?  I can’t stand blurry things, they always
make me think there is something wrong with my eyes!  
(Unless of course that is the purpose of the blurry text.)  ;-)

Rick

> On Mar 29, 2018, at 11:35 AM, David V Glasgow via use-livecode 
>  wrote:
> 
> I want to give users options for capturing anonymised cards, and wondered 
> about blurring text - maybe by overlaying a graphic of the text and blurring 
> that? 

___
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: Selection Handles

[Mike Bonner via use-livecode]

I see, yeah.  And rolling your own full blown selection scheme would be a
bit much.

On Thu, Mar 29, 2018 at 1:17 PM, Knapp Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Mike. The app allows the user to be in standard LC edit mode to
> select any of the objects, either by clicking on them or dragging a
> selection rectangle around them. And I do have tools that allow the user to
> select multiple objects and then align, layer, make the same size etc.
> Perhaps I could implement a scheme where if the user selects only 1 line it
> then deselects and pops up my own selection handles, though that might be a
> bit ugly.
>
> > On Mar 29, 2018, at 12:02 PM, Mike Bonner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Since you already have code in place to use your homegrown selection
> > handles, can you adjust things so that the line doesn't actually have to
> be
> > "selected" to make changes? My guess is that the small button you
> > implemented can be dragged, and then you do your magic and adjust length
> > while constraining to horizontal or vertical.  I don't see why the line
> > would actually have to be selected to do this.
> >
> > On Thu, Mar 29, 2018 at 12:52 PM, Knapp Martin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I have an app that I'm migrating from LC 6.6.5 to 8.1.9. In it, a user
> >> creates documents that may consist of lines, boxes, text areas and
> images
> >> that they insert. There's been a big change between 6.6.5 and 8.1.9 in
> the
> >> selection handles on objects. In 6.6.5, the selection handles on lines
> were
> >> really tiny so I implanted a scheme - when the line is selected I
> overlay a
> >> small button at each end that you drag to change the length and another
> in
> >> the middle to grab the line to move. A side benefit of this is that no
> >> matter how "wobbly" the user is in dragging my selection handles, I've
> >> scripted it so the line stays perfectly horizontal/vertical.
> >>
> >> In LC 8.1.9 the selection handles on lines are huge in comparison, and
> are
> >> centered over the middle of the end point, making it trickier to align
> to
> >> another object (a frequent thing in my app). While I can live with it
> >> myself, for my customers I'm way less than thrilled. Often times there
> is
> >> the need to create several short lines in close proximity to each other.
> >>
> >> In 8.1.9 I can't use my own selection handles like I was as they end up
> >> *behind* those of LC and must exist on a layer above everything else - a
> >> change from 6.6.5.
> >>
> >> So my question is, is there any way to change the selection handle
> >> behavior - something even that is a hack? They're fine on everything
> else,
> >> it's just on lines that it becomes an issue for me. I’m anticipating a
> “no”
> >> but thought I’d ask!
> >>
> >> Marty
>
> ___
> 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: Selection Handles

[Knapp Martin via use-livecode]

Thanks Mike. The app allows the user to be in standard LC edit mode to select 
any of the objects, either by clicking on them or dragging a selection 
rectangle around them. And I do have tools that allow the user to select 
multiple objects and then align, layer, make the same size etc. Perhaps I could 
implement a scheme where if the user selects only 1 line it then deselects and 
pops up my own selection handles, though that might be a bit ugly.

> On Mar 29, 2018, at 12:02 PM, Mike Bonner via use-livecode 
>  wrote:
> 
> Since you already have code in place to use your homegrown selection
> handles, can you adjust things so that the line doesn't actually have to be
> "selected" to make changes? My guess is that the small button you
> implemented can be dragged, and then you do your magic and adjust length
> while constraining to horizontal or vertical.  I don't see why the line
> would actually have to be selected to do this.
> 
> On Thu, Mar 29, 2018 at 12:52 PM, Knapp Martin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I have an app that I'm migrating from LC 6.6.5 to 8.1.9. In it, a user
>> creates documents that may consist of lines, boxes, text areas and images
>> that they insert. There's been a big change between 6.6.5 and 8.1.9 in the
>> selection handles on objects. In 6.6.5, the selection handles on lines were
>> really tiny so I implanted a scheme - when the line is selected I overlay a
>> small button at each end that you drag to change the length and another in
>> the middle to grab the line to move. A side benefit of this is that no
>> matter how "wobbly" the user is in dragging my selection handles, I've
>> scripted it so the line stays perfectly horizontal/vertical.
>> 
>> In LC 8.1.9 the selection handles on lines are huge in comparison, and are
>> centered over the middle of the end point, making it trickier to align to
>> another object (a frequent thing in my app). While I can live with it
>> myself, for my customers I'm way less than thrilled. Often times there is
>> the need to create several short lines in close proximity to each other.
>> 
>> In 8.1.9 I can't use my own selection handles like I was as they end up
>> *behind* those of LC and must exist on a layer above everything else - a
>> change from 6.6.5.
>> 
>> So my question is, is there any way to change the selection handle
>> behavior - something even that is a hack? They're fine on everything else,
>> it's just on lines that it becomes an issue for me. I’m anticipating a “no”
>> but thought I’d ask!
>> 
>> Marty

___
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: Selection Handles

[Mike Bonner via use-livecode]

Since you already have code in place to use your homegrown selection
handles, can you adjust things so that the line doesn't actually have to be
"selected" to make changes? My guess is that the small button you
implemented can be dragged, and then you do your magic and adjust length
while constraining to horizontal or vertical.  I don't see why the line
would actually have to be selected to do this.

On Thu, Mar 29, 2018 at 12:52 PM, Knapp Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I have an app that I'm migrating from LC 6.6.5 to 8.1.9. In it, a user
> creates documents that may consist of lines, boxes, text areas and images
> that they insert. There's been a big change between 6.6.5 and 8.1.9 in the
> selection handles on objects. In 6.6.5, the selection handles on lines were
> really tiny so I implanted a scheme - when the line is selected I overlay a
> small button at each end that you drag to change the length and another in
> the middle to grab the line to move. A side benefit of this is that no
> matter how "wobbly" the user is in dragging my selection handles, I've
> scripted it so the line stays perfectly horizontal/vertical.
>
> In LC 8.1.9 the selection handles on lines are huge in comparison, and are
> centered over the middle of the end point, making it trickier to align to
> another object (a frequent thing in my app). While I can live with it
> myself, for my customers I'm way less than thrilled. Often times there is
> the need to create several short lines in close proximity to each other.
>
> In 8.1.9 I can't use my own selection handles like I was as they end up
> *behind* those of LC and must exist on a layer above everything else - a
> change from 6.6.5.
>
> So my question is, is there any way to change the selection handle
> behavior - something even that is a hack? They're fine on everything else,
> it's just on lines that it becomes an issue for me. I’m anticipating a “no”
> but thought I’d ask!
>
> Marty
> ___
> 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

Selection Handles

[Knapp Martin via use-livecode]

I have an app that I'm migrating from LC 6.6.5 to 8.1.9. In it, a user creates 
documents that may consist of lines, boxes, text areas and images that they 
insert. There's been a big change between 6.6.5 and 8.1.9 in the selection 
handles on objects. In 6.6.5, the selection handles on lines were really tiny 
so I implanted a scheme - when the line is selected I overlay a small button at 
each end that you drag to change the length and another in the middle to grab 
the line to move. A side benefit of this is that no matter how "wobbly" the 
user is in dragging my selection handles, I've scripted it so the line stays 
perfectly horizontal/vertical.

In LC 8.1.9 the selection handles on lines are huge in comparison, and are 
centered over the middle of the end point, making it trickier to align to 
another object (a frequent thing in my app). While I can live with it myself, 
for my customers I'm way less than thrilled. Often times there is the need to 
create several short lines in close proximity to each other.

In 8.1.9 I can't use my own selection handles like I was as they end up 
*behind* those of LC and must exist on a layer above everything else - a change 
from 6.6.5.

So my question is, is there any way to change the selection handle behavior - 
something even that is a hack? They're fine on everything else, it's just on 
lines that it becomes an issue for me. I’m anticipating a “no” but thought I’d 
ask!

Marty
___
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: How to handle BasicAuth in Browser widget?

[Richard Gaskin via use-livecode]

Thanks, Monte.  Any guidance on what I might tell that new user in the 
forums?


--
 Richard Gaskin
 Fourth World Systems

Monte Goulding wrote:

> I think we would either need to add support for a callback or present
> a dialog natively. It might be possible to handle the load failed
> callback and check the error string then specify the username and pass
> in the URL though...
>
>> On 29 Mar 2018, at 4:17 am, Richard Gaskin wrote:
>>
>> This forum post is an interesting problem:
>> https://forums.livecode.com/viewtopic.php?f=7=30796
>>
>> By what means can our stacks use the standard Basic Auth dialog when
>> going to a page that requires it in the Browser widget?
>> --
>> Richard Gaskin



___
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: variable xref

[Mark Waddingham via use-livecode]

On 2018-03-28 15:45, Mike Kerner via use-livecode wrote:
Heck no.  I spend way too much time in environments that were written 
to

make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.


Heh - I'm not sure that the necessity to predeclare things in many 
languages can just be put down to 'making the compiler writer's job 
easier' - even if you go back 'just' 15 years, computers were nowhere 
near as powerful as they are today and most of the languages which exist 
today have a history which goes back wy further.


If things are not pre-declared then you need at *least* two passes to 
compile a program. Each pass requires a linear traversal of the input to 
the pass. If you require the programmer to pre-declare then you can 
compile in a single pass in many cases (a technique called 
syntax-directed translation). If you don't pre-declare then the first 
phase has to parse all the syntax into structures without knowing how 
they fit together, and then you have to iterate over those structures 
defining the 'names' in appropriate scopes and *then* you have to 
iterate over those structures again to link up the uses of the names to 
the definitions.


(You can merge the declaration and parsing phases - but not the 
declaration, parsing and definition phases - hence why you have a 
minimum of two passes in a language which does not require 
pre-declaration).


Of course, in a dynamic environment like LiveCode where code is split up 
and insulated into multiple distinct much smaller texts, and you can 
defer action until use, pre-declaration is not really required (and 
indeed it is not) - you can amortize the cost of the notional passes 
over the time the program is running rather than having to do it all 
ahead of time.


Nothing makes code less readable than re-using i, j, k, l, and m 
because
you don't feel like using a readable loop counter because you'll have 
to

fix the declaration.


I must confess I still use i, j, k etc. type variable naming - but only 
when I want the index and element in numeric arrays or if I'm writing 
code which is doing maths where the equations use such index notation:


  repeat with i = 1 to the number of elements in tVar
-- now I can mutate the elements of tVar as it loops
  end repeat

I'm not sure why I've got into that habit though - its not really a good 
one! Although I don't think it does much harm if the loops are only two 
or three lines long.


Of course, if you happen to have an non-optimizing lower-level compiler, 
then re-using variables can make a huge difference to code performance 
as you can be more sure a register will be used (assuming the data type 
is appropriate) - that being said 32-bit intel architectures have never 
really had that issue as they have virtually no registers anyway! 
(Fortunately something which the 64-bit variant has fixed!).



I want the best of both worlds, and mostly I want the machine to do the
work, not me.  I'm busy.


Indeed, the work has to be done at some point, by somebody/thing - the 
balance is whether you want to pay the cost:
  1) waiting for things to compile (a full recompile of the engine on 
Mac OS X used to take 15-20mins when I first got it; although the record 
was apparantly 8 hrs on the AIX box MetaCard used to have - and C/C++ 
*requires* predeclaration for most things).
  2) over the lifetime of the execution of the program (or at the start 
if you use a lot of code at startup)

  3) by the programmer whilst writing the code

That all being said, variable analysis could be done better in all 
languages I think - although it isn't the easiest of problems or things 
to get right. Python I think might be *slightly* better than LiveCode's 
(its somewhere between explicitVars = true and explicitVars = false - 
and doesn't require declaration). On the other hand, Python doesn't have 
a mode where you can have bare literals (which require significant 
context analysis to work out whether they are variables are not unless 
you do all the work whilst executing the code - which is essentially 
what LiveCode does when explicitVars are false - so you pay for that 
with a performance cost and not knowing whether you've made an error 
before you run).


I think it would be generally true to say that most programming 
languages are designed to keep any context-sensitive information 
required compile/execute them to the bare minimum - and any which is 
required can be collected in very fast and efficient ways. For humans 
this is very unintuitive though - if nothing else, humans are generally 
quite good at very quickly guessing at the correct context of things 
when there is a paucity of information - computers may have caught up a 
bit speed wise to allow greater contextual awareness (just because they 
are faster with more storage/memory) but programming languages perhaps 
have not...


My general feeling that there is a better balance lurking - somewhere 
between 

Re: LCG Session Suggestions

[Lagi Pittas via use-livecode]

Oops forgot the link to the B4J library


https://www.b4x.com/android/forum/threads/sd-bluetooth-printer.85750/

Lagi

On 28 March 2018 at 14:36, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Looking for suggestions for sessions for LCG, whether advanced, beginner,
> or somewhere in between
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: LCG Session Suggestions

[Lagi Pittas via use-livecode]

Hi Mike

Two very  useful sessions (for me anyway) and the ones that would produce
code that everyone can use when we share the results is using
 FFI for  Android/Java , Windows and IOS No  3 sessions Android/Java,
Windows and IOS and Linux No 4 .. nobody expects the Spanish
Inquisition ...


All joking apart for me at the moment in Order Android and Windows FFI
would be be the most useful - for two reason.

On the Android front I want to encapsulate the Java SDK calls for Star or
Epson Bluetooth Receipt printers and maybe get this Eddyston/Beacons show
on the road(I think others on this list might agree that would be awesome).

To save time here is a library for B4J (its the java version and it is
totally free - for commercial use as well), I have   B4A (and B4 for IOSI)
if Livecode can't do it but the "designer" if you can call it that leaves a
lot to be desired. I would love to be able to code my lowlevel stuff in B4A
(it's closer to the metal) but use Livecode for the GUI stuff.

Now if we had a way of encapsulation Python code  Ali/Mark over to
you?

Another  session would be how to encapsulate Windows DLLs using FFI - so
many libraries for different languages  that we could use as is.

Regards Lagi



On 28 March 2018 at 14:36, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Looking for suggestions for sessions for LCG, whether advanced, beginner,
> or somewhere in between
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: Blurring field contents

[Paul Hibbert via use-livecode]

That tutorial is a bit outdated now that there is a “blur” command, introduced 
in LC 8.0, it’s quicker and easier to use.

Paul

> On Mar 29, 2018, at 8:35 AM, David V Glasgow via use-livecode 
>  wrote:
> 
> I want to give users options for capturing anonymised cards, and wondered 
> about blurring text - maybe by overlaying a graphic of the text and blurring 
> that?  
> 
> There is an LC tutorial about blurring images 
> , 
> but it seems complex for simply blurring names and addresses in a couple of 
> fields.
> 
> Any suggestions?
> 
> 
> Best Wishes,
> David Glasgow
> 
> 
> 
> ___
> 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: Blurring field contents

[Mike Bonner via use-livecode]

You could set the imagesource of the characters into the field, take the
snapshot,  then "set the text of field "whatever" to the text of field
"whatever" to revert.
Did a quicky test, and it seems to work well enough.
local simageOn
on mouseup
lock screen
   if sImageOn is empty then put false into sImageOn
   if sImageOn then
  set the text of field 1 to the text of field 1
  put false into sImageOn
   else
  repeat with i = 1 to the number of chars in field 1
 set the imagesource of char i of field 1 to 1008
  end repeat
  put true into sImageOn
   end if
unlock screen
end mouseup

On Thu, Mar 29, 2018 at 9:46 AM, Tore Nilsen via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Why not just hide the fields in question before exporting the snapshots
> and then showing them after the export is done? This way you do not have to
> work with the exported image.
>
> Regards
> Tore Nilsen
>
> > 29. mar. 2018 kl. 17:35 skrev David V Glasgow via use-livecode <
> use-livecode@lists.runrev.com>:
> >
> > I want to give users options for capturing anonymised cards, and
> wondered about blurring text - maybe by overlaying a graphic of the text
> and blurring that?
> >
> > There is an LC tutorial about blurring images <
> http://lessons.livecode.com/m/4071/l/26580-vision-how-do-i-blur-an-image>,
> but it seems complex for simply blurring names and addresses in a couple of
> fields.
> >
> > Any suggestions?
> >
> >
> > Best Wishes,
> > David Glasgow
> >
> >
> > 
> > ___
> > 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: Blurring field contents

[Tore Nilsen via use-livecode]

Why not just hide the fields in question before exporting the snapshots and 
then showing them after the export is done? This way you do not have to work 
with the exported image.

Regards
Tore Nilsen

> 29. mar. 2018 kl. 17:35 skrev David V Glasgow via use-livecode 
> :
> 
> I want to give users options for capturing anonymised cards, and wondered 
> about blurring text - maybe by overlaying a graphic of the text and blurring 
> that?  
> 
> There is an LC tutorial about blurring images 
> , 
> but it seems complex for simply blurring names and addresses in a couple of 
> fields.
> 
> Any suggestions?
> 
> 
> Best Wishes,
> David Glasgow
> 
> 
> 
> ___
> 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

Blurring field contents

[David V Glasgow via use-livecode]

I want to give users options for capturing anonymised cards, and wondered about 
blurring text - maybe by overlaying a graphic of the text and blurring that?  

There is an LC tutorial about blurring images 
, but 
it seems complex for simply blurring names and addresses in a couple of fields.

Any suggestions?


Best Wishes,
David Glasgow


 
___
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: Make an open stack modal by script

[Richard Gaskin via use-livecode]

Ah, yes - the *property* is read-only; I had mistakenly read that as 
being about the stack itself somehow being read-only.


Yes, the relationship between mode, style, and the mode commands 
(toplevel, palette, modal, modeless) are wonderfully flexible.


Mode lets us know what state the window is in at any given time.

Style lets us set a mode as a default when we use open or go.

The mode commands let us override that style to open a stack of any 
style in any mode as needed.


In devolution's DeskView window I use these to allow easy toggling of 
modes by double-clicking the window representation within it:


If that stack's style is toplevel it bring it to the front as toplevel.

If the style is anything else it uses the toplevel command so I can work 
on it.


If its mode is already toplevel but its style is not, it reopens the 
stack in its style.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

> The Property called mode is read only. The mode is set using the style
> keyword as was pointed out. That works a peach! I had been jumping
> through hoops to prevent users from accidentally switching a customer
> or site while editing a device record belonging to one of those two.
> Now I just set the style to "Modal" while editing and return it to
> "TopLevel" when not.
>
> Bob S
>
>
>> On Mar 28, 2018, at 10:00 , Richard Gaskin wrote:
>>
>> Bob Sneidar wrote:
>>
>> > Unfortunately, and to my great chagrin, the mode of a window
>> > is read only.
>>
>> What does that mean?  What exactly do you see?
>>
>> I can't think of any mode that prevents text entry, so maybe you've
>> encountered a bug, or some other script is preventing editing.
>>
>> --
>> Richard Gaskin

___
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