All Answers

I’m not sure I understand the issue. The properties are serialized when their value is set and different from the base value. I tried adding removing the AppearanceKey but those properties, if not set before, they remain not set and show the color from the theme. If you want to reset the properties right click on it and select Reset.

Yes, thank you. Seems to be a bug in the base js library. It’s almost invisible with blue-1. Will log and should be fixed in the next build.

Ciao.
the example that I am attaching is an example present in your documentation
wisej-examples-2.0 \ Buttons

It works!
I was referring to the internal “button / icon”
Thanks!

Please attach a small sample showing the issue. I cannot reproduce.

That’s not what I get and “button” refers to the button not the inner “button/icon”. Can you attach a small sample?

Thanks but so it colors the border of the image, not the button.

Thank you, Luca.

Following your answer, I added a new button on my form and set its AppearanceKey to the one I defined in the mixin and it works indeed without a problem. So why not for the “old” buttons which are already on my form?

Well, I think I found what the problem is. Before playing with the appearances, I had tried changing the Forecolor and Backcolor “by hand” in the properties of those “old” buttons. But the hovering effect cannot be added through the properties in the designer, so I decided to create the mixin. Before applying the mixin, I reset the Forecolor and Backcolor to their original values @buttontext and @buttonface by double clicking in the properties row, opening the color picker form and selecting the @buttontext and @buttonface colors from the Theme Colors. But what that did, was to introduce those lines in the .designer.cs file. For a new button, those lines are not present, as they are considered defaults which do not need to be explicitly included. As soon as I removed those lines for the “old” buttons from the .designer.cs file, the appearance workd correctly.

So, if I set the color values back to their defaults and the lines are inserted in the .designer.cs, somehow they intervene with the appearance, the AppearanceKey is probably ignored! I could have seen there was a difference if I had noticed that in the properties, the colors I set show up in bold @buttonface and @buttontext, although these are their default values, see the attachment.

Best,
Alex

The missing appearances warnings are normal. There are hundreds of child widgets that don’t have a specific appearance defined in the theme.

I tried your mixin and works fine. Recopied it below.

{
 "name": "Material-3.mixin",
 "fonts": {
 "default": {
 "size": 18,
 "family": [ "roboto", "verdana", "arial" ]
 }
 },
 "colors": {
 "buttonFace2": "#F1F5F2"
 },
 "appearances": {
 "patientMenuButton1": {
 "text": "Patient",
 "inherit": "menubutton",
 "states": {
 "default": {
 "properties": {
 "show": "both"
 },
 "styles": {
 "backgroundColor": "red"
 }
 },
 "pressed": {
 "styles": {
 "transform": null
 }
 },
 "hovered": {
 "styles": {
 "backgroundColor": "red"
 },
 "properties": {
 "cursor": "pointer"
 }
 }
 }
 }
 }
}

Yes, you can change the border under the “hovered” state or under the “pressed” state in a theme mixin or in a custom theme:

{
 "appearances": {
  "button": {
   "inherit": "button",
    "states": {
     "hovered": {
      "styles": {
      "color": "green",
      "width": 2
     }
    },
    "pressed": {
     "styles": {
      "color": "blue",
      "width": 4
    }
   }
  }
 }
}
}

Hi Edmond,

To handle a SAML workflow you need a Default.aspx page and process the POSTed XML in the code behind. As you would do in a plain ASP.NET page. That will happen before your wisej app is loaded: the loading of the Wisej app happens when the browser is done loading the <script src=”wisej.wx”/> tag in the Default.aspx (or Default.html) page.

The code behind in aspx runs before since it runs on the server before the page is returned to the browser. There you can receive the SAML POST, process it, and pass it to the Wisej app using Wisej.userData in aspx:

<script>
  Wisej.userData = <%= a string from the aspx code that can also be a JSON string %>
</script>

On the server side you will find the object in Application.Browser.UserData.

If the app is already started and the user is coming back you will get the Application.ApplicationRefresh event.

The workflow is identical to ASP.NET. It will be documented in detail in the upcoming extensive documentation we are building.

HTH

If you don’t set the icon it will not show. See:

https://wisej.com/docs/2.2/html/P_Wisej_Web_Form_Icon.htm

https://wisej.com/docs/2.2/html/P_Wisej_Web_Form_IconSource.htm

https://wisej.com/docs/2.2/html/P_Wisej_Web_Form_IconLarge.htm

https://wisej.com/docs/2.2/html/P_Wisej_Web_Form_IconLargeSource.htm

The screenshots are for the theme builder, which sets the icon “icon-window” for the preview.

Once you set the icon on the form will show.

The icon is defined in the theme, but in the runtime form the icon does not appear, and there is no way to show the icon either … I will send an image as an example …

In attachment print1 you can see that the icon shows in the taskbar, but in the print2 the icon just doenst show up.. Do i have to set it? Because on WiseJ Theme Updater it shows like the attachment print3.

Hi Ruben,

what´s your intention by setting the icon through the theme?
Did you see the form properties Icon, IconLarge and IconSource in the designer?

If they are not good for you, please explain what you are trying to achieve.

Best regards
Frank

Dear Luca and Frank,
Hope you are both well and safe in these terrible times we are all going through.
Thanks for the answers and the immediate fix. Just tried it and it looks like working correctly.
All the best,
Alex

I added Wisej.Web.Ext.Brotli.dll to the project.
However, I can not see the br in the request header. It showed only gzip, deflated

I used Edge and Chrome with the latest wisej 2.2.21

I could not see the frames either.

Hi Alex,

hope you´re doing fine, thanks for reporting these issues.

The bug is logged as #2483 and enhancing the Designer as #2484.

I´m happy to let you know that both are fixed in our latest Wisej development build (2.2.21).

Best regards
Frank

And the combination of AutoSize of the FlowLayout with the textboxes with FillWeight. Looks like a circular layout issue.

Seems to be the combination of MinimumSize and MaximumSize with the FillWeight and AutoSize that messes it up. If you remove the MinimumSize  and use FlowBreak and MaximumSize seems to be OK. I will log the issue.