All Answers

Thanks Cris,

I have logged it as WJ-7366

Best regards
Frank

Thanks Nic,

this issue is logged as WJ-7364.

Best regards
Frank

Hi Nic,

thanks for your description and test case.

I have logged the problem as WJ-7363.

Best regards
Frank

Handle Applicaton.SessionTimeout on the server. I’m not sure if you have to do something else. I haven’t tried this scenario. Frank will verify and get back to you. If his office in Germany is dry.

I’m OOTO until middle of next week.

I have seen it working, we have several tests. I will send you one later on today.

Make sure the timer is ticking and *there is a handler attached* Basically every time there is a round trip all pending updates are sent back.

Best,

Luca

Luca,

Just to update you on this. I’m still stuck on Windows 7 (new machine on order :)) so I tried the timer work around you suggested. It doesn’t appear to make any difference. I still do not see the changes made on the second thread. Maybe it just won’t work without websockets?

Nic

Looks like you have a busy weekend ahead of you then 🙂

Thanks – I look forward to playing with all the new toys next week.

Nic

Hi Luca,

When I drop the combobox, the default properties are:

AutoSize = True
Font = @default, 13px, Regular
Size.Height = 30

At runtime, the height looks bigger than the textbox to the right of the combobox. Please see the attached project I am playing with.

By the way, I’ve also noticed something about Label when adding a Height property in the Theme Builder. I’ll send it later.

Regards,

Cris

Actually no, let me correct my last statement. Even if AutoSize=false and the height is smaller than the theme height, Wisej resizes the control correctly. The bottom part gets truncated only if the height is smaller than the internal elements, in the combobox case it’s the button which has a minimum height.

Hello Cris,

What is the font of the page/form? I found a potential problem in the calculation of the preferred height but I can’t reproduce this specific issue.

This is how the system calculates the height of controls:

• When AutoSize=false, the  height set by the code is preserved. We added AutoSize to all editable controls to let developers set the height of the fields to design moder looking apps. Changing the theme won’t change the height since it’s set in th code.
• When AutoSize=true, the height is set using a combination of the theme and the font. The system calculates the height of the font (adds 25%, the potential problem I mentioned is that it always added 7 pixels) adds the insets (size of the border if any, read from the theme) and then compares with the height in the theme. It will return the biggest of the two.

The problem you are seeing means that the theme height is bigger than the control’s height, which is impossible since the property PreferredHeight always returns the biggest height and that is what is used when AutoSize = true.

The only way I can reproduce this  problem is by setting AutoSize=false and a height that is smaller than the height set in the theme.

Can you please check if you have AutoSize=false and also the font please?

Thanks,

Luca

Thanks. Reproduced and logged: WJ-7355.

Ciao Luca,

thank you for your answers. I give you the details you asked for:

• According to the ComboBox, in VWG we often use it to show other controls, i.e. the MonthCalendar, when opening the drop down list, as you can see in the attached example. We do this by intercepting the GetCustomDropDown event.
• We use EnterKeyDown to allow Users moving from field to field using Enter key instead of Tab, in order to ensure compatibility with WinForms applications.

I take this opportunity to ask some other questions:

• In VWG we use the ComboBox DropDownWidth property: will it be available in Wisej?
• Does the TabPage HeaderToolTip property exist?
• About the DataGrid control:
  • Is there a method like FirstDisplayedCell (which is present but read-only) to set the first visible cell?
  • CaptionHeight and BorderWidth properties are not present: will they be available?
  • SelectedCells property is not present: will it be available?
• In VWG we use Application.SetThreadBookmark to simulate page change: how can we do it in Wisej?
• In VWG we use Screen.PrimaryScreen.WorkingArea.Width to evaluate the available area dimension: how can we do it in Wisej?

Thank you very much!

Hi Luca,

You are correct that size doesn’t change at runtime. The runtime screenshot was taken from Chrome zoomed at 125%. Didn’t know and notice that it was set like that. Sorry for the false alarm

But the issue for combobox (logged as WJ-7347) is still the same.

Regards,

Cris

OK, see it. That should be the blank area between the last column and the visibility menu. If you set the columns to AutoSizeMode=Fill then they will spring to fill the grid. I also see the “$h” text in the column header of the row header column. Which I have seen before but could never reproduce but now I can after resetting some style properties. So that will also be logged and fixed.

Actually from your screenshot the controls did indeed change size. Can you send me the test project? Chrome or IE? I can’t reproduce. See my screenshot below.

Best,

Luca

Hi Luca,

As shown in the image attached, it is to the left of the grid menu (as you call it).

Also, take note of the extra characters appearing on the upper-left corner of the DGV.

Regards,

Cris

Do you mean the column with the grid menu?

If yes, that’s not a column, it’s the column visibility menu (ShowColumnVisibilityMenu property – can set it to false to hide it). With one of the early Material-3 themes the icon was not visible so it looked like an extra column.

If not, please send me a screenshot and also check what name the column got if it’s visible in the columns editor.