Force a redraw or refresh of the screen...[Solved]

[bogs]

I was wondering if there was a keyword, command, or function in Lc I am unable to find to force a screen refresh or redraw.

I wrote a handler to scale controls in a program which is called from the resizeStack handler/message.

One of the things I noticed running it is that when I resize the stack, sometimes the controls don't *look* like they finished, but if I then move the window, they *are* in fact correctly set.

I initially thought of lock/unlock screen, but on reading the comments in the reiszeStack entry it says

The screen is locked while a resizeStack handler is running, so it is not necessary to use the lock screen command to prevent changes from being seen. (However, the lockScreen property is not set to true.)

Then I looked for redraw/refresh, but only found references for mobile or the browser.

As a work around for now, I simply have the resizing handler call another handler that runs it one extra time, but obviously this isn't ideal, least not in my opinion

[LiveCode_Panos]

Hello bogs,

Try the following:

Code: Select all

set the backcolor of this card to the backcolor of this card

This should force a screen redraw.

Kind regards,
Panos
--

[bogs]

Hm. That is an approach I didn't think of (and pretty darn neat), but didn't solve the problem. I can see i'll have to test this on a supported version in a modern distro to see if it is an issue there, but this is what I'm seeing happen.

The handler called from 'resizeStack' (with my workaround, and your suggestion -

Code: Select all

on scaleControls tmpSet
   set the width of field "textEditor" to the width of this card -3
   set the height of field "textEditor" to the height of this card -84
   set the bottom of field "filePath" to the bottom of this card -1
   set the bottom of field "saved" to the bottom of this card -1
   set the bottom of field "characterCount" to the bottom of this card -1
   set the width of field "filePath" to the width of field "textEditor" -202
   set the width of group "textEditor" to the width of this card
   set the height of group "textEditor" to the height of this card
   set the backcolor of this card to the backcolor of this card
   /* if tmpSet is "0" then break
   endScale */
end scaleControls

on endScale
   scaleControls("0")
end endScale

Resize the stack....

Resize...

Move the window...

Moved by titlebar...

Time to go setup a virtual machine again

[FourthWorld]

What does the resizeStack handler look like?

[bogs]

Literally it just sends that handler (least, I don't think I messed it up too much)

Code: Select all

on resizeStack
   if the short name of this stack is "textEditor" then
      send "scaleControls(1)" to group "textEditor" of this card
   end if
end resizeStack

[[-hh]]

Code: Select all

on scaleControls
   if "scaleControls" is in the pendingMessages then exit scaleControls
   lock screen; lock messages # <-------
   ...
   -- always forces a redraw if needed:
   -- set the backcolor of this card to the backcolor of this card
end scaleControls

[FourthWorld]

Offhand I don't see why that shouldn't work, but the screen shot looks like the UI is cycle or two behind where we would expect it to be, something I've seen when I've done unusual things with my resizeStack handlers, or haven't set the lockLoc of the group.

What happens if you set the rect of the group from the card's resizeStack handler, and let the group use the resizeControl message to trigger updating its internal controls?

That's a useful pattern for handling resizing in general, since it lets you card/stack handle the UI in blocks, and the blocks sort themselves out, keeping layout details encapsulated as you have them now but with the additional benefit of being extensible and portable.

But even without that natural-message-path approach, the fix may be as simple as locking the loc of the group, since an unlocked group will adjust itself to fit controls, and the controls are moving around in ways that may affect others during the sequence as a byproduct of adjusting the group.

[bogs]

@ -hh,
That did indeed create the refresh needed at the end of the resizing, but wound up creating other issues while resizing ...

While resizing...

The previous code kept the edge of the fields pretty close to the edge of the card, still noticeable but to a lesser extent.

Offhand I don't see why that shouldn't work, but the screen shot looks like the UI is cycle or two behind where we would expect it to be, something I've seen when I've done unusual things with my resizeStack handlers, or haven't set the lockLoc of the group.

Yes, that is exactly how it behaves. After a resize where it didn't 'appear' to line everything up right, simply moving the window by the titlebar *did* show that it was lined up.

I did actually have the lockLoc set on all controls, not just the group, which is why I am manually resizing the group itself.

All locked up...

Maybe I should take the lockLoc off the group and try it again, I usually lock everything during the design phase to make sure I don't accidentally move something

*Edit - apparently that was the cause of the problem, the code where I set the width of the group (which was locked) wasn't keeping up with everything else. When I unlocked the group, the final move does snap it to where it should be.

I'll have to play with some of the suggestions more to see if some combination overcomes this issue.

[FourthWorld]

Locking the loc is rarely a mistake for resizing, avoiding the side-effects of groups resizing themselves to fit the code. I would leave it locked.

Feel free to send me the stack if you like and I'll poke around to see how this can be resolved.

[[-hh]]

Just noticed that you are probably on LC 6 or 7.
Then you could use

Code: Select all

set the liveResizing of this stack to false

ResizeStack fires to often for all your "manual" updates when liveResizing is true.

And: Did you already try the geometry manager?

[bogs]

Yes, sorry, I should have at the top put that I am writing this in 6.5.2 on MX Linux vers. 18

I did use the geometry manager a few times when I started using Lc. I even read the dissertation on it in the resources back then -

Management...

My general experience with it was that it would (for the most part) work fine *if* you never ever not ever planned to change anything, but for anything else, you are probably better off coding it, even if you wrote out more statements than you needed just to cover everything.

Even in those situations where I know without a doubt I won't be changing something later, since I used it so infrequently it takes me a good re-read (or 3) of that piece about it before I remember exactly how to use it again.

It took me nearly half a year to find a well explained (but very old) article about the basics on how to write a resize handler. It was written for Mc. The lesson I found about scaling erm...only seemed targets on mobile.

As for the liveResizing, that was already unchecked by default -

Is it live, or memorex?

Selection_005.png (20.95 KiB) Viewed 8655 times

Maybe I should try checking it, I had no idea what it controlled, since the stack seemed to be resizing already

I have to say, though, I am learning a LOT today, you guys are awesome!

*Edit - ok, I unchecked that liveResizing again
I don't know why it would affect this, but it blew out my minWidth and height setting It also didn't apparently change anything in the way the stack displays while actually resizing, at least not on this OS. Very weird, but set to off for sure !

[bogs]

On re-reading this entire thread, I found I forgot to answer this part of Richard's post -

What happens if you set the rect of the group from the card's resizeStack handler, and let the group use the resizeControl message to trigger updating its internal controls?

I actually didn't test this out, because the application creates new cards on the fly. My thinking was if I put it in the resizeStack of the first card, when a new card was created it wouldn't have that handler, would it?
I'm know I can code it in to be placed in the script of every new card that gets made, I just didn't think it would require that kind of resolution.

I've been wrong before, though

[bogs]

I finally decided to see if it was something the geometry manager would handle better than I was doing, so I created a separate stack with 4 fields to represent the fields I'm interested in moving/scaling, locked the position on all of them, then grouped them and locked the groups position.

Then I set the group and main fields geometry to scale like so

Group and field...

Selection_002.png (9.63 KiB) Viewed 8577 times

I set the 3 remaining fields to position

Bottoming out...

Selection_003.png (11.16 KiB) Viewed 8577 times

and the last field I added the scale to the right edge.

I then tested doing the following (all of these tests are in 6.5.2) -
* In edit mode, resized the window, controls resized and refreshed at the end, but lagged behind the window resizing same as pictures above. I then remembered reading (somewhere) that the lock screen isn't triggered during debugging, which I took to mean edit mode, so I switched to browse mode, and eventually suspended the dev environment. No matter the mode, though, the stack always resized with the same issues. All the following were also run in all 3 modes, including as a standalone.
* I then set 'liveResize to true, this made no difference as far as I could tell. Since I have now learned what liveResize does (I looked it up), it seemed this would actually be the best shot at having it work correctly, but as far as I could tell visually, it changed little.
* I then set the acceleratedRendering for the stack to true, this did not appear to do much except to add a black or transparent visual glitch. I would say it does not affect the compositor the XFCE desktop uses in a good way. I set it back to false.
*Edit - I forgot to add the picture of the acceleratedRendering resize -


* lockLoc on or off didn't seem to make a difference when using the geometry manager. I did finally see the issue Richard was talking about with the groups behavior if coded manually.
* Ungrouped the controls - this came the closest to what I would expect to happen, with the least amount of visual glitching/lag.

I think in my own projects, I might have to seriously consider skipping grouping and create templates instead for anything that needs to resize with the window and be placed on new cards. At least from what I think I am seeing, the group lags behind everything else when being resized by a noticeable margin.

After I finish this project, I'll have to go do some testing in the more modern versions of Lc if this is not the expected behavior.
The geometry manager test stack in all its glory as a standalone -

Geo-managerific...

*Edit - I did complete some generic testing in 8.1.2. I was surprised I couldn't find 'liveResizing' or 'acceleratedRendering' in the properties dialog in the inspector, but using the messagebox I turned both on /off.

There have been a lot of improvements in this area, but it still lags on the resize. I am beginning to think this is normal behavior at this point. Testing was done with the geometry manager test stack used in this post.

[bwmilby]

I’ve submitted some patches to the GM in the 9.0 series, so any bug behavior should be checked in the latest version. I don’t think anything I touched would impact what you are seeing though. Most was related to properly being able to clear GM settings and ensuring that adding multiple new controls wouldn’t result in ID mis-assignment (logic had the IDs assigned one off in some cases which would manifest as stuff moving incorrectly after a resize).

[bogs]

Over night, I'll be running some of these tests on a Windows 7 vm (closest I get to a win computer) in Lc 9.0.1 and the latest 9.0.2 version I could find. The vm runs a completely bone stock Win7 image updated manually (i.e., no Win10 changes garbage). I may also wind up running the tests on a similarly bare XP rig if time permits.

I suspect heavily that what I am seeing is a combination of things, the way XFCE/lightdm works, the way the XFCE compositor works (the visual glitches when using acceleratedRendering). The controls lagging as far as they do really appears affected by being in the group, when out of the group, they resize much much faster. I think I'll be changing that scaling handler to control just the groups height/width, and break the fields out into a separate handler to run after the group is the right size and see if that makes it better or worse