Re: Locking the Display of Individual Stacks (was Re: Possible data grid bug?)

[J. Landman Gay]

Scott Rossi wrote:

Recently, Jacque Landman Gay wrote:


Scott Rossi wrote:

For folks who would like to be able to lock the display of one stack while
displaying status in another stack:



Good. I added a suggestion.



lock screen = current behavior, no updates anywhere
lock window  = lock only the referenced window


When I was trying to think of syntax, I initially thought "lock stack" could
be an option, but then realized this could imply making a stack non-writable
-- not good.  If "window" is a synonym for "stack", then maybe locking this
object still implies making the object non-writable, but I will admit,
subjectively, "lock window" *sounds* OK to me.

Wasn't as easy a task as I initially imagined :-)


Doesn't matter. If Mr Waddingham implements it, he's likely to have his 
own syntax ideas. And to be honest, most of the time he's right. :)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Locking the Display of Individual Stacks (was Re: Possible data grid bug?)

[Scott Rossi]

Recently, Jacque Landman Gay wrote:

> Scott Rossi wrote:
>> For folks who would like to be able to lock the display of one stack while
>> displaying status in another stack:
>> 
>> 
> 
> Good. I added a suggestion.

> lock screen = current behavior, no updates anywhere
> lock window  = lock only the referenced window

When I was trying to think of syntax, I initially thought "lock stack" could
be an option, but then realized this could imply making a stack non-writable
-- not good.  If "window" is a synonym for "stack", then maybe locking this
object still implies making the object non-writable, but I will admit,
subjectively, "lock window" *sounds* OK to me.

Wasn't as easy a task as I initially imagined :-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


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

Re: Locking the Display of Individual Stacks (was Re: Possible data grid bug?)

[J. Landman Gay]

Scott Rossi wrote:

For folks who would like to be able to lock the display of one stack while
displaying status in another stack:




Good. I added a suggestion.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Locking the Display of Individual Stacks (was Re: Possible data grid bug?)

[Scott Rossi]

For folks who would like to be able to lock the display of one stack while
displaying status in another stack:



Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


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

Re: Possible data grid bug?

[Scott Rossi]

Recently, Jacque Landman Gay wrote:

>> Actually Jacque, I don't believe this is the case.  If you issue lock screen
>> from any open stack (or even the message box) any visual updates in *all*
>> open stacks are halted.  At least they are on my end (Rev 4).  You can test
>> this using some simple test stacks that run looping animations.  I posted a
>> question on this issue to the list some time ago.  The current (?) lock
>> screen behavior makes it impossible to run any progress indication while the
>> screen is locked because the screen is truly "locked".
> 
> Oops. Thanks Scott. I guess I haven't checked on it in a while. Could
> have sworn it used to behave like HC did (did this change at some point
> or have I been wrong all along?)

Dude, this was exactly my point of my post!  I could have sworn lock screen
only locked the window from which it was issued.  Maybe folks who have older
versions of Rev can see whether this was the case before Rev 3/4.
Regardless, it would make a useful enhancement request/bug fix.  I'll write
one up.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


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

Re: Possible data grid bug?

[J. Landman Gay]

Scott Rossi wrote:

Recently, Jacque Landman Gay wrote:


The "lock screen" command should really be called "lock window". It only
prevents redraw in the front window. So you could put up a small
substack that contains only your progress bar and run it from there
while the window behind is locked and busy over on the other card.


Actually Jacque, I don't believe this is the case.  If you issue lock screen
from any open stack (or even the message box) any visual updates in *all*
open stacks are halted.  At least they are on my end (Rev 4).  You can test
this using some simple test stacks that run looping animations.  I posted a
question on this issue to the list some time ago.  The current (?) lock
screen behavior makes it impossible to run any progress indication while the
screen is locked because the screen is truly "locked".


Oops. Thanks Scott. I guess I haven't checked on it in a while. Could 
have sworn it used to behave like HC did (did this change at some point 
or have I been wrong all along?) I shouldn't have skipped that last 
brain updater I guess. Apologies to the list for the misdirection.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Possible data grid bug?

[Scott Rossi]

Recently, Jacque Landman Gay wrote:

> The "lock screen" command should really be called "lock window". It only
> prevents redraw in the front window. So you could put up a small
> substack that contains only your progress bar and run it from there
> while the window behind is locked and busy over on the other card.

Actually Jacque, I don't believe this is the case.  If you issue lock screen
from any open stack (or even the message box) any visual updates in *all*
open stacks are halted.  At least they are on my end (Rev 4).  You can test
this using some simple test stacks that run looping animations.  I posted a
question on this issue to the list some time ago.  The current (?) lock
screen behavior makes it impossible to run any progress indication while the
screen is locked because the screen is truly "locked".

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


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

Re: Possible data grid bug?

[J. Landman Gay]

Jeffrey Massung wrote:


The end goal is to actually go to the card with the DG on it, but

while it's filling in with its initial dataset, I'm showing a progress
indicator. Locking the screen prevents the progress indicator (an
animated GIF in this instance) from updating.

The "lock screen" command should really be called "lock window". It only 
prevents redraw in the front window. So you could put up a small 
substack that contains only your progress bar and run it from there 
while the window behind is locked and busy over on the other card.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Possible data grid bug?

[Jeffrey Massung]

On Feb 27, 2010, at 5:39 PM, Sarah Reichelt wrote:
> 
> So basically, you can't do what you have in mind.
> Would it work to lock the screen, go to the second card, draw the DG
> and then go back to where you were?

This is what I've done to fix the problem (and how I first learned that 
changing cards works). Sadly, this defeats my UI goals, but I'm sure I can come 
up with something else.

The end goal is to actually go to the card with the DG on it, but while it's 
filling in with its initial dataset, I'm showing a progress indicator. Locking 
the screen prevents the progress indicator (an animated GIF in this instance) 
from updating.

Thanks for the reply and link, though!

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

Re: Possible data grid bug?

[Sarah Reichelt]

On Sun, Feb 28, 2010 at 6:55 AM, Jeff Massung  wrote:
> I have an interesting situation here, and likely this is just a bug on my
> end, but thought I'd toss it out and see if maybe it's not me. Essentially,
> I'm trying to fill in data for a data grid that's on another card that isn't
> the current card.
>
> I'm using "of me" everywhere and - in fact - all my data does get added to
> the DG. But a whole lot of exceptions are thrown from elsewhere (deeper in
> the DG behavior), causing sections of my code to not execute. Result: bugs.
> If I switch cards first, then dispatch the commands, no exceptions are
> thrown.

Check out 
.

One of the paragraphs says:

Don't try to draw a Data Grid on a card that Is not open
When a Data Grid renders it dynamically creates fields and accesses
certain properties. Some of these properties can not be properly
reported by the Revolution engine unless the field is on an open card.

So basically, you can't do what you have in mind.
Would it work to lock the screen, go to the second card, draw the DG
and then go back to where you were?

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

Re: Possible data grid bug?

[Jeff Massung]

Bob,

Thanks for the reply. I am doing all those things [properly]. I'm triple
checking my code to make sure, but it's not that complex:

from card A:

   - dispatch "msg" to grp "dg" of cd "b" with arguments


group DG:

   - addData tData


DG behavior script:

   - Many uses of "of me" - as to be expected


Like I said, if I go to card B before the dispatch, everything is fine. If I
do the dispatch from card A then the data is added, but many exceptions are
thrown (not in fillInData or layoutControl).

Something unique that I do is each row of the datagrid on FillInData will do
a "load URL with callback". Perhaps that callback is causing issues?

Thanks again for the reply.

Jeff M.

On Sat, Feb 27, 2010 at 4:02 PM, Bob Sneidar  wrote:

> Hi Jeff.
>
> The only place you can use "of me" is in the script of the DG object
> itself. If the script you are setting the dgText is in another object, then
> you have to use "of group ". If you call it from another card,
> then you have to add the reference of the card: "of group  of
> card ". If you still throw errors, you may have
> uncovered a bug with behaviors.
>
> Bob
>
> On Feb 27, 2010, at 12:55 PM, Jeff Massung wrote:
>
> > I have an interesting situation here, and likely this is just a bug on my
> > end, but thought I'd toss it out and see if maybe it's not me.
> Essentially,
> > I'm trying to fill in data for a data grid that's on another card that
> isn't
> > the current card.
> >
> > I'm using "of me" everywhere and - in fact - all my data does get added
> to
> > the DG. But a whole lot of exceptions are thrown from elsewhere (deeper
> in
> > the DG behavior), causing sections of my code to not execute. Result:
> bugs.
> > If I switch cards first, then dispatch the commands, no exceptions are
> > thrown.
> >
> > Anyone else tried this before or have any ideas what might be causing my
> > issues?
> >
> > Jeff M.
> > ___
> > use-revolution mailing list
> > use-revolution@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
>
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Possible data grid bug?

[Bob Sneidar]

Hi Jeff. 

The only place you can use "of me" is in the script of the DG object itself. If 
the script you are setting the dgText is in another object, then you have to 
use "of group ". If you call it from another card, then you have 
to add the reference of the card: "of group  of card 
". If you still throw errors, you may have uncovered 
a bug with behaviors. 

Bob

On Feb 27, 2010, at 12:55 PM, Jeff Massung wrote:

> I have an interesting situation here, and likely this is just a bug on my
> end, but thought I'd toss it out and see if maybe it's not me. Essentially,
> I'm trying to fill in data for a data grid that's on another card that isn't
> the current card.
> 
> I'm using "of me" everywhere and - in fact - all my data does get added to
> the DG. But a whole lot of exceptions are thrown from elsewhere (deeper in
> the DG behavior), causing sections of my code to not execute. Result: bugs.
> If I switch cards first, then dispatch the commands, no exceptions are
> thrown.
> 
> Anyone else tried this before or have any ideas what might be causing my
> issues?
> 
> Jeff M.
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

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

Possible data grid bug?

[Jeff Massung]

I have an interesting situation here, and likely this is just a bug on my
end, but thought I'd toss it out and see if maybe it's not me. Essentially,
I'm trying to fill in data for a data grid that's on another card that isn't
the current card.

I'm using "of me" everywhere and - in fact - all my data does get added to
the DG. But a whole lot of exceptions are thrown from elsewhere (deeper in
the DG behavior), causing sections of my code to not execute. Result: bugs.
If I switch cards first, then dispatch the commands, no exceptions are
thrown.

Anyone else tried this before or have any ideas what might be causing my
issues?

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