All Answers

Hi Luca,

Can I have the fix to make sure this is the problem?

Best,
Alex

Because it depends on the sequence of events and if wisej has something to update on the textbox losing the focus. If the selection is set before the focus update then it’s fine, or if there is not selection change it’s also fine. To reproduce consistently I removed Wisej focus management in the test and let the browser handle it.

Another issue can be that now Wisej executed the actions after yielding to the browser to let it update the screen.

In any case, it’s very easy to fix.

Now if I say I understood, I’ll be lying…

The question is, can it be fixed? And why don’t I see it on all forms? And why couldn’t you reproduce it? Concerning browsers, it shows up in Chrome, IE, Edge, Firefox. In Opera the result is much worse, since the focus is completely lost and after a few tab clicks it focuses on a hidden control showing its border… Is it an effect of the latest build/latest qooxdoo?

Alex

Bug. When is set to a separator it’s serialized differently and the visible property seems to be missing.

Thanks for spotting that.

Best,

Luca

It’s the selection range. Wisej is also able to manage the selectedText, start, length in the text fields. But apparently some browsers change the focus, some don’t, chrome was undecided, and it has been an issue for a while. So qooxdoo normalized it to always set the focus when setting the selected text. When wisej updates the controls on the client it may update the selection too and it will cause the focus to jump back.

Hi Luca,

This has been posted as fixed in Build 1.2.25.

The message doesn’t touch the right border but the message is not complete. Missing “v1.2.XML ” in the message box

Thanks.

Hi Luca,

Got it. But can’t set the separator’s Visible property to false. Is it by design?

And thanks for your info about panel’s header. I’ve tested that and works great.

Regards.

And ??

🙂

Hi Cris,

To push the button to the right you should put in a separator and set the separator to Fill. The buttons to the right of the separator will dock to the right. See image below.

If you set fill on the button, the button will expand to use the available space. You can set SizeMode.Fill on multiple buttons to have them resize proportionally.

HTH

Best,

Luca

Hi Frank,

Please see attache image how the ToolBar looks if I set SizeMode=Fill. A right-aligned toolbar button can work as a “Close” button of a UserControl loaded inside a form. In my opinion, it doesn’t look good and needs more  improvement especially when the mouse is over the button.

Thanks.

Got it.

Hi Luca,

Thanks for the update.

You are right, I don’t see it with ForeColor anymore. To be honest, I had seen it a while ago, and since I remembered I couldn’t change color, I tried to change style yesterday. And when I saw that style didn’t change I thought it was the same effect I had seen earlier with colour and reported it. But I was obviously wrong. The colour was either fixed since the day I saw it, or I had too much beer that day. Sorry.

Alex

You can enable console logging on the client using “debug”:true. In VS you can see the traces from Wisej in view->output. I don’t think it will help by looking at the logs. A lot of stuff happens simultaneously. But I think you are right, it’s related to firing back the events. I will try that. I have an idea of what it may be.

Hi Luca,

This won’t be easy…

Well, it has to do certainly (big word!) with the text change event. I can see it also when tabbing between the textboxes, not only when mouse-clicking.

The reason I suspect the text change is that if I press a letter in the textbox and tab to the next textbox, the cursor comes back, and if I tab again, the focus moves to the next textbox. If however, after the first return to the first textbox, I type another letter and tab, the cursor returns to the first control, i.e., whenever there is a change, it returns, if there is no change it proceeds…

I have removed my textbox validation events (which fired on text change) but the behaviour is the same. I have seen it a couple of times (but not always) disappear, if I do not run in debug mode. I also played with both values of the “optimizeFrames” flag, true and false, but didn’t see a difference.

Is there a way to check javascript events?

Alex

It’s a bug when using a theme font as the base. Logged as WJ-7469.

Theme fonts have the OriginalName starting with @. Like the theme colors. When you use new Font(font, style) System.Drawing copies over also the OriginalName and Wisej detects it as a theme font and doesn’t check if it was altered. If you create the font using the name it works.

You can also define several theme fonts and use them by name, like new Font(“@mybold”, …). Wisej will use the “mybold” font in the theme. Which can also be a webfont. The new build will also recognize SystemFonts by name if they are defined in the theme.

Cannot reproduce the issue with ForeColor.

Best,

Luca

Hi Alex, I can’t reproduce. Will keep trying. I have seen something similar in the past and it was caused by a mismatch between the focused control on the client and  the server.

Absolutely! I made the same mistake… WJ-7472. Will throw an exception that shows as a message box on the client.

Hi Luca,

How can I access the .json file contents from within the server code? In the scenario we have been talking with each client having their own clientX.json, it would be great to put client-specific setting in the individual .json files, but can we read them later?

Best,
Alex