Hi Klaus,
> On Apr 4, 2021, at 4:50 PM, Klaus major-k via use-livecode
> wrote:
>
> Hi Roger,
>
>> Am 05.04.2021 um 00:56 schrieb Roger Guay via use-livecode
>> :
>>
>> Hi all,
>>
>> I have a button on one stack that hides and shows controls of another stack.
>> Is it possible to add Lock
Hi Roger,
> Am 05.04.2021 um 00:56 schrieb Roger Guay via use-livecode
> :
>
> Hi all,
>
> I have a button on one stack that hides and shows controls of another stack.
> Is it possible to add Lock screen for effect and Unlock screen with effect in
> that button? Can’t seem to make it work….
Good idea. I myself have not encountered a situation where I need multiple
handlers that lock the screen. Everything I do is database oriented anyway, so
there is inevitably lots of idle times. If I ever do need this your idea seems
the most reasonable way to go.
Bob
On Sep 21, 2012, at
Message-
From: Bob Sneidar b...@twft.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Mon, Sep 24, 2012 12:24 pm
Subject: Re: lock/unlock screen
Good idea. I myself have not encountered a situation where I need multiple
handlers that lock the screen. Everything I do is database
On Mon, Sep 24, 2012 at 9:38 AM, dunb...@aol.com wrote:
This has been echoed by others, correctly. You cannot guarantee that your
screen will
be unlocked with that one-liner. Unless you get back to idle, multiple locks
are queued,
and the screen will remain locked until they are all purged.
I moved my code to preOpenStack - I still see the change in location on the
screen. It appears I will have to resort to some subterfuge like the one
suggested by Scott, or opening the stack invisible initially to make this
work.
From the dictionary:
The *preOpenCard* message
On 09/23/2012 07:31 PM, Peter Haworth wrote:
I moved my code to preOpenStack - I still see the change in location on the
screen. It appears I will have to resort to some subterfuge like the one
suggested by Scott, or opening the stack invisible initially to make this
work.
Try my suggestion
: lock/unlock screen
On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote:
Face it Richmond. It's you and me against the world. ;-)
If you can't sleep at night because you're worried about multiple lock
screen, or keeping track of pairs, why not:
if the lockScreen is false then lock
@lists.runrev.com
Sent: Fri, Sep 21, 2012 11:43 pm
Subject: Re: lock/unlock screen
On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote:
Face it Richmond. It's you and me against the world. ;-)
If you can't sleep at night
I haven't been sleeping very well recently, but, largely owing to my
On 09/22/2012 08:36 PM, Peter Haworth wrote:
Here's another nuance on lock screen, throwing in preOpenCard processing
just for good measure!
My preOpenCard code includes lock and unlock screen commands. While the
screen is locked, I alter the stack's topLeft property, expecting that the
user
Thanks Richmond, I'll give that a try. I'm also unsure as to whether lock
screen has any effect in the preOpenxxx handlers since the screen isn't
even displayed at that point. But I guess it can't do any harm.
Pete
lcSQL Software http://www.lcsql.com
On Sat, Sep 22, 2012 at 10:41 AM, Richmond
One of the advantages of using a splashstack, ie, a stub mainstack that opens
the actual user interface, is that you can implement the positioning and
appearance of your user interface stack before you open it. E.g.: in your
mainstack, you set the rect of the interface stack, the visible
On 09/22/2012 08:56 PM, Peter M. Brigham wrote:
One of the advantages of using a splashstack, ie, a stub mainstack that opens
the actual user interface, is that you can implement the positioning and
appearance of your user interface stack before you open it. E.g.: in your
mainstack, you set
On 9/22/12 12:36 PM, Peter Haworth wrote:
My understanding of preOpenCard is that it happens before the stack is
displayed so this behavior puzzles me.
PreOpenCard happens after the stack window is drawn and before the card
is drawn. PreOpenStack happens before the stack is displayed.
FWIW, in most cases a preOpenStack or preOpenCard handler in the card
script of the first card should be enough to position/orient a stack. If
you try to set stack properties like windowShape or shadow, those actions
can cause the stack to become visible before positioning takes place
because
You could always use a workaround, when you absolutely positively have to
unlock the screen:
on reallyUnlockScreen
repeat until the lockscreen = false
unlock screen
end repeat
end reallyUnlockScreen
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
On Sep
On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote:
Face it Richmond. It's you and me against the world. ;-)
If you can't sleep at night because you're worried about multiple lock
screen, or keeping track of pairs, why not:
if the lockScreen is false then lock screen
If you
On 09/19/2012 09:16 PM, Bob Sneidar wrote:
Okay I modified Richmond's experiment to include a send mouseup to button Single
Undo at the end of the first buttons script, and the field does indeed remain
hidden, so yes a series of screen locks do stack. Pardon me for the false info.
I was
Richmond-
Thursday, September 20, 2012, 1:29:32 AM, you wrote:
That 'multiple lockscreen' thing does seem illogical and/or daft, and it
might not be a bad thing if it were changed so that 'locked' meant
'locked once' and was not ambiguous.
It's actually quite useful as is. It means I can
I agree with Richmond. I cannot think of a case where I would want to lock a
screen multiple times and then incrementally unlock the screen, knowing that
the screen is still locked! I can think of examples where I would want to lock
then unlock the screen while the script was still executing,
On Thu, Sep 20, 2012 at 8:30 AM, Bob Sneidar b...@twft.com wrote:
I agree with Richmond. I cannot think of a case where I would want to lock a
screen multiple
times and then incrementally unlock the screen, knowing that the screen is
still locked!
I have several; it's quite common in what I'm
The nested handler situation mentioned by Bob and Dr Hawkins are where the
layered lock/unlock is useful.
Pete
lcSQL Software http://www.lcsql.com
On Thu, Sep 20, 2012 at 8:30 AM, Bob Sneidar b...@twft.com wrote:
I agree with Richmond. I cannot think of a case where I would want to lock
a
On 9/20/12 10:30 AM, Bob Sneidar wrote:
I agree with Richmond. I cannot think of a case where I would want to
lock a screen multiple times and then incrementally unlock the
screen, knowing that the screen is still locked! I can think of
examples where I would want to lock then unlock the screen
2012/9/20 J. Landman Gay jac...@hyperactivesw.com:
On 9/20/12 10:30 AM, Bob Sneidar wrote:
I agree with Richmond. I cannot think of a case where I would want to
lock a screen multiple times and then incrementally unlock the
screen, knowing that the screen is still locked! I can think of
SO . . .
there is a 'political divide' over those who think that multiple
lockscreens followed by multiple
unlockings is a good thing, and those who think it is a bad thing.
What to do ?
Well, here's a thought . . .
Would things not be easier to understand if each subsequent lockscreen
was
Face it Richmond. It's you and me against the world. ;-)
Bob
On Sep 20, 2012, at 2:07 PM, J. Landman Gay wrote:
On 9/20/12 2:31 PM, Richmond wrote:
Would things not be easier to understand if each subsequent lockscreen
was signalled in some
sort of way so one can keep track of all the
Bob Sneidar bobs@... writes:
Face it Richmond. It's you and me against the world.
Uh oh. Look out, world.
--
Mark Wieder
mwie...@ahsoftware.net
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe,
Peter.
Pretty sure this follows the HC way, in that lock screen commands are queued,
and must be unlocked the same number of times they are locked.
You can always throw in:
repeat until the lockScreen is false
unlock screen
end repeat
Craig Newman
-Original Message-
From:
In a prior post I seem to recall that the screen will unlock at the first idle
message, no matter how many lock screens have been issued. Also, I think it's a
one dimensional command, that is, the screen will unlock as soon as you issue
an unlock screen.
Bob
On Sep 19, 2012, at 10:08 AM,
Thanks Craig.
Pete
lcSQL Software http://www.lcsql.com
On Wed, Sep 19, 2012 at 10:08 AM, dunb...@aol.com wrote:
Peter.
Pretty sure this follows the HC way, in that lock screen commands are
queued, and must be unlocked the same number of times they are locked.
You can always throw in:
OK, seems like there's conflicting opinions then. I guess I can use
Craig's idea of checking the lock screen to see how it unfolds.
Pete
lcSQL Software http://www.lcsql.com
On Wed, Sep 19, 2012 at 10:22 AM, Bob Sneidar b...@twft.com wrote:
In a prior post I seem to recall that the screen
Richmond had a genius moment :)
I made a wee stack called LOCKER with
two buttons; Triple-Play and Single Undo and
a fld fff containing the text UNLOCKED!
the script of btn Triple-Play goes like this:
on mouseUp
set the vis of fld fff to false
set the lockscreen to true
set the
After putting some displays in my code, it seems that the locks are queued,
that is unlocking only unlocks the last lock, not all of them.
However, it also seems that the unlock doesn't take effect until the
handler it is in exits. For example, F1, calls F2 and F2 locks and
unlocks. A check of
On 9/19/12 12:52 PM, Richmond wrote:
Richmond had a genius moment :)
I made a wee stack called LOCKER with
two buttons; Triple-Play and Single Undo and
a fld fff containing the text UNLOCKED!
the script of btn Triple-Play goes like this:
on mouseUp
set the vis of fld fff to false
set
Right, because you are actually executing each command as a single script when
in debug mode, hence idle gets sent right after. Idle unlocks the screen. Also,
it seems you and Richmond are getting different results. Not sure what is going
on there.
Bob
On Sep 19, 2012, at 10:58 AM, Peter
That won't work Richmond, unless the first button sends a mouseup to the second
button. Remember, an idle message will unlock the screen in any event, so as
soon as the first button's script finishes, the screen will unlock.
Bob
On Sep 19, 2012, at 10:52 AM, Richmond wrote:
Richmond had a
Okay I modified Richmond's experiment to include a send mouseup to button
Single Undo at the end of the first buttons script, and the field does indeed
remain hidden, so yes a series of screen locks do stack. Pardon me for the
false info.
Bob
On Sep 19, 2012, at 10:52 AM, Richmond wrote:
Interesting Richmond, and different than what I'm seeing. Maybe the
difference is that your locks are all in the same handler and mine
are scattered across different ones?
Pete
lcSQL Software http://www.lcsql.com
On Wed, Sep 19, 2012 at 10:52 AM, Richmond richmondmathew...@gmail.comwrote:
OK, I think this all hangs together now. I guess the only thing to watch
out for might be an unlock screen with no associated lock screen since it
sounds like that would have the potential to unlock the screen too early.
Not likely to happen though.
I was hoping this discussion might solve a
No chance you can 'batch' the updates ?
put fld someField into temp
repeat with i = 1 to (many thousands)
put someUpdate(i) after temp
end repeat
put temp into fld someField
will be *so* much faster ...
-- Alex.
On 19/09/2012 19:57, Peter Haworth wrote:
OK, I think this all hangs
On 09/19/2012 09:16 PM, Bob Sneidar wrote:
Okay I modified Richmond's experiment to include a send mouseup to button Single
Undo at the end of the first buttons script, and the field does indeed remain
hidden, so yes a series of screen locks do stack. Pardon me for the false info.
Right, I
Hi Alex,
I wish I could! The problem is that I'm setting the textshift and
imagesource of a specific character in each line. I tried putting
everything into a variable first but the textshift and imagesource
properties aren't available in variables.
I'm currently experimenting with putting html
42 matches
Mail list logo
