All Answers

Hi Mark,

ListBox items don’t have a Selected property, they are just objects. I tried to iterate the listbox.SelectedItems collection and it is always correct. Can you send a test case?

Best,

Luca

Hi Cris,

The session timeout form needs only to kill the session. The OK button should simply close the dialog (you can have a non-modal showing the modal mask).

The system implementation starts a javascript loop for the countdown and then calls Wisj.Core.exit() on the client when the countdown expires. If you click OK it closes the form and terminates the countdown. If you have a “Kill” button, make it call Application.Exit(). Just closing the form refreshes the session – any action that causes a request/response refreshes the session timeout.

You can find all the configuration options, including custom options, in Application.Configuration. Application.Configuration.SessionTimeout is what you are looking for. Application.Configuration.Settings is a dynamic object where you can retrieve application specific settings from Default.json.

Changing SessionTimeout programmatically is difficult because it is sent back to the client before your code is called, in response to the init request. The client uses it to manage the timeout timer. Then the SessionManager sets the expiration timeout at SessionTimeout * 2 when adding the session to the cache.

You can have multiple .json files pointing to the same entry point and have different values: Client1.json, Client2.json, etc. All referring to the the same Main method. The URLs would be http://server/client1, http://server/client2.

Another option would be to add a custom cache provider in Web.config. It’s an easy implementation, the default is attached. To replace it add the full name of the type to an appSettings named “Wisej.CacheProvider”.

HTH

Best,

Luca

Hi Dario,

Found what has changed and what most likely is the problem. 18 was the last build that directly set the HTML code used in the internal renderer. After 18, the HTML used in the renderer is loaded as a URL from the internal web server used at design time. Your machine is probably blocking the internal web server.

We always had it but before (18 and below) is was used mainly to load resources (images, embedded resources) at design time and if it failed you would notice only when trying to load certain resources. However, it relied on setting the <base> url otherwise the base was “file:///….” and this doesn’t work for css files and creates other problems.

Making the internal renderer fully based on localhost:[port] allows the designer to correctly display third party widgets, load css resources, embedded images, and solves all the problems that a “file:///  url created.

Your machine policy probably blocks System.Net.HttpListener (this is not a firewall issue). Can you please try to run VS as Administrator and see if it makes a difference? We’ll add a check for this and try to display a meaningful message.

/Luca

Sorry, forgot to reply about the VWG theme:

The closest we have in terms of metrics is Classic-2 which is also modeled after Windows 10. VWG has an XP theme then upgraded to look like Vista, and a couple of other themes that were never really completed: Facebook and GoogleMail.

Did you try Classic-2?

/Luca

Hello Dario,

I have never seen this issue before. I tried with VS 2015 Community on a W10 virtual machine and it works here.

We are diffing 18 and 35 to see what may have changed in the designer rendering area. From the screenshot it looks like the designer renderer failed to load, see that the title (part of the non-client (NC) area) is at the bottom meaning that he calculated NC area starts at 0,0 which is wrong. It could also mean that the current theme failed to load.

Can you please try this:

• Delete C:\Users\[User Name]\AppData\Local\Temp\Wisej\IDE.
• Try on a different PC or VM.
• Contact me directly at gianluca[at]iceteagroup.com – I could give you a debug build to track down the issue.

Best,

Luca

We can’t do that using the component’s Docking and Anchoring layout engines. Docking and Anchoring is based on the DisplayRectangle and in the Desktop control it’s the workspace area, otherwise controls would dock over the taskbar, while we want the taskbar to “reduce” the workspace area.

However, you can do this by altering the client side layout – and I’d like to explain this code a bit (OT: we are working on a blog where all this technical digressions can be published…).

Wisej’s controls have a double life: the server side component and the client side widget. The server side component manipulates the client side widget as a whole and manages the layout between the components. The client side widget manages its internal layout and child widgets entirely on the client side.

So… The Desktop component on the server knows only about the desktop widget and certain metrics, like the non-client area, borders, theme padding, colors, etc. Doesn’t know anything about the internal layout of the desktop widget and its child widgets, in this case the child widgets are “workspace” and “taskbar”.

The “taskbar” child widget is positioned at the bottom because it has a layout property named “edge” set to “south”. The parent desktop widget uses the “Dock” layout engine.

In your code, if you set the Dock property of the status bar to None and add the code below on startup, the status bar will dock below the taskbar.

this.statusBar1.Eval(
@”this.addListener(‘appear’, function(){
this.resetUserBounds();
App.Desktop._addBefore(this, App.Desktop.getChildControl(‘taskbar’), {top:null, left: null, edge:’south’});
});”
);

The code above executes on the client when the status bar “appears”, which means that the corresponding html element is created and made visible, it removes the location and size set by the server, it changes the layout parent and docks it under the taskbar child widget.

HTH

Best,

Luca

Same results with 1.3.27 and the new 1.3.35.

I’m stuck with 1.3.18

Hi Felix,

WJ-7973 is fixed in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Mark,

WJ-8003 is also fixed in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Mark,

hovered state has been added (WJ-7997) in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Mark,

WJ-7996 is fixed in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Tung,

WJ-8006 is also fixed in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Tung,

WJ-8008 is fixed in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Andrew,

both fixes (WJ-8022+WJ-8023) are included in the latest Wisej release (1.3.35).

Best regards
Frank

Hi Cris,

Having said that, wouldn’t it be more user friendly that whenever I click an Appearance key in the left pane, Editor scrolls down
or up to its corresponding line.

Logged as WJ-8024, included in latest Wisej release (1.3.35).

Best regards
Frank

Hi Tung

WJ-8004 has been included in Wisej release 1.3.35.

Best regards
Frank

Also included in the latest release (1.3.35).

Best regards
Frank