OLD FORUM - Use new one: https://www.CaptainCasa.online/forum

I already recently asked how to dynamically scale the CC Client using code and/or UI element.
That generally worked pretty well, but now that we're planning to implement it we've found a couple of minor annoyances and problems which we'd like to fix first:

1. When changing the scaling, the screen flashes two times. I can only guess about that, but as far as I know, CC first rescales the UI and then the fonts. Or the other way around.

Does it change the sizefactor and fontfactor variables one by one?
Can we reduce the screenflashing to _1_ flash per scalechange?
Or does it need to complete the UI rearrangement (after changing size- or fontfactor first) to guess and approximate the new UI sizes?

2. We want to allow a user to set a custom scaling (from 50%-200%) and start the client in that scaling.
However, since the function to change the scaling is embedded in a CC element ( t:clientconfig, attribute "scale"), we first have to load the UI with a basic scaling, requesting the starting page from the server and inflating the whole UI, retrieve the user-specific scale from the DB and the client rescales.
As described in 1., two screen-flashes happen.

Does the client load and request the "starting page" two additional times (once per screenflash) compared to starting the client in a default scaling?
Or does it simply rescale the UI locally, without re-requesting the starting page from the server?

3. IF the starting page is requested two additional times:
To reduce load on the server when users are starting up their CC-workplace and since our start-page is customizable and rather complex...
Can we somehow let the client dynamically start up with a user-specific scaling OR avoid inflating the whole UI before we've set the scale?

IF that isn't possible:
Can we somehow get a trigger or a hook which would tell the client when the inflating is done?
We'd just show a simple "Welcome" splash screen, wait until the CC started up with the standard scaling, load and apply the user-specific scaling, and when the trigger/hook says, that it's done with that, we'd load the actual UI, avoiding two additional, very ressource intensive roundtrips with a lot of searching and building up fixgrids.

A lot of our users said that, while it doesn't seem to be completely fixed, it's a lot better. We'll need to figure out the remaining complaints on a case to case basis, because some of them might be caused by our type of implementation (and some of them might be intended).

So far thanks a lot for your help, again!

After our current build goes through QA and gets deployed, we'll actively test it with the new CC version.

Thanks a lot with your help so far, I'll be back when we figure out if this fixed the problem!

Worked great, thanks a lot!

I've read this:
http://www.captaincasademo.com/forum/posts/list/998.page

But we're coming back to that point. We launch the Client with a standardized scaling setting. Some users of our client would like for the CC Client to remember their personal scaling setting.

So we would need a way to save the current scaling setting for the next starts of the application.

Some users also asked for a more comfortable way to change the scaling.
Currently the user would need to click on the "settings wrench", click the scaling settings textfield, type in a new number and click okay.
4 user actions to change that on every start of the application might be a bit much (since they can't save their personal, optimal scaling setting). Would an optional scaling shortcut setting be possible in the client? Screenshot attached how it could look (missing proper labels right now).

*bump*

Also wanted to tell you that the semi-fix doesn't seem to work all the time.
("It seems to have been fixed by setting the fixgrid attribute "avoidroundtrips" to "true". ")

It still happens occasionally, they said it fixes the problem like "99%" of the time. But since it still happens, it seems like we're still not at the root of the problem.

I've attached two screenshots.
As I've said, we're unable exactly pinpoint it.

But we stumbled over a (possible) solution. One person in our team _always_ "suffered" under this unusual behavior. It seems to have been fixed by setting the fixgrid attribute "avoidroundtrips" to "true".

We'll do some further testing trying out that solution.

We've got a weird problem which we're unable to precisely pin down.

When we put links in a column in a fixgrid, sometimes some Users have to click these links two times (doesn't matter if it is a straight up doubleclick or a click-pause-click).

We've got Users to whom that never happened, Users to whom that happened, then, with an CC Framework update or Java update it disappeared or the other way around (suddenly they had that problem).

We checked the Framework versions (we just deployed), the Java versions, but we are unable to pin it down to one factor or a precise combination of factors. Sometimes of two Users with the same setup one had the problem and the other one did not.

We're (wildly) guessing that it may have to do with the way Userevents/clicks are passed from the fixgrid to subelements (links)?

Maybe it does have something to do with a combination of the Java and/or CC-Framework version?

Did anybody have any similar problems?
Does anybody have an idea for a (sensible) workaround?
Even if not, do you have any relating ideas?

As far as I know it's an older version, I guess we should update again. We'll check tomorrow and I'll report back.

Setup:
We extensively use foldablepane components in our application.
A lot of them have their "opened" attribute set to "false" statically in the CC editor.

Old behavior:
However...
they used to retain their opened state, after it has been opened by a user interaction, even when we changed to another tab and then back again to the UI-site which used the foldablepane component.

New behavior:
It also seems like server roundtrips (we use them, for example, in UIs used to search for specific items. You can find the expanded/advanced search options inside the foldablepane), like after our search button has been pressed, reset their state back to false, even though they used to maintain their user-set state.

Questions:
Is that a bug?
If not, is it a new feature/bugfix?
If yes, could the old behavior be made into an option?
If not, how can we (as easily as possible) revert back to the old behavior?
It would otherwise require us to add and manipulate code on a lot of UIs and we'd prefer to keep it as simple as possible.

Notice:
Before sb. asks why we want to maintain that behavior:
In case the user uses the advanced search options and presses search, we'd like to remind him that he set these advanced options in case he instantly wants to tweak his/her search and repeats it / switches to another tab and back again. If we automatically close the foldablepane component, the user might not notice that he still uses advanced search options, which will influence the result, which might contradict the outcome he predicted based on the search options which he modified in the always visible basic search option area.

*bump* since we could need an update about the bug considering paste/cut functions within textpanes.