All Answers

Hi Tim,

This is the mixin to change the drop down button icon and size. It uses a file url so the icon resource must be deployed with the app. You can also turn it into a data string and embed it in the mixin. It sets the size to 32,32. See screenshot below.

{
“appearances”: {
“checkbox”: {
“inherit”: “checkbox”,
“components”: {
“icon”: {
“inherit”: “icon-dark”,
“states”: {
“default”: {
“properties”: {
“width”: 32,
“height”: 32
}
}
}
}
}
},
“combobox”: {
“inherit”: “combobox”,
“components”: {
“button”: {
“states”: {
“default”: {
“properties”: {
“icon”: “combobox-dropdown.gif”
}
}
},
“components”: {
“icon”: {
“states”: {
“default”: {
“properties”: {
“width”: 32,
“height”: 32,
“scale”: true
}
}
}
}
}
}
}
}
}
}

HTH

Best,

Luca

It was logged as WS-8279 and is now fixed for ComboBox and ListBox.

Thanks!

Hi Tim,

The size of the icon doesn’t change with the font, it’s in the theme. Add a theme mixin file to the /Themes folder (I use Application.mixin.theme) where you can add all the theme changes your app needs without modifying the theme files. This is to change the size of the checkbox icon and override the current theme’s settings.

{
“appearances”: {
“checkbox”: {
“inherit”: “checkbox”,
“components”: {
“icon”: {
“inherit”: “icon-dark”,
“states”: {
“default”: {
“properties”: {
“width”: 32,
“height”: 32
}
}
}
}
}
}
}
}

I also still owe you the same for the combobox. Will reply to the other post shortly.

/Luca

Hi Cris,

The position of drop down menus related to buttons is “burned” in the code as “bottom-right”. It aligns the menu to the bottom and the right of the opener (in this case the button that opened it). MPlacement also uses best fit, so when the window is maximized it cannot align the right edges because it would go outside of the browser and be hidden so it aligns to the left instead because “placementModeX” defaults to “keep-align”.

You can find more info about the MPlacement mixin here: http://www.qooxdoo.org/current/api/#qx.ui.core.MPlacement

Look at the properties position and placementModeXY. The menu class inherits the MPlacement mixin.

All the placement properties are themeable but the Wisej classes set”position” to “bottom-right” because the theme properties are applied to the “menu” appearance key which is valid for all menus.

You can change placementModeX to “best-fit” in the theme for the “menu” key:

This change would make the popup menu move to the right only as much as needed.

{
“appearances”: {
“menu”: {
“inherit”: “menu”,
“states”: {
“default”: {
“properties”: {
“placementModeX”: “best-fit”
}
}
}
}
}
}

Or you can change the position by overriding the ToolbarButton class that has a drop down menu:

public class MyButton : ToolBarButton
{
public override void Update()
{
if (((Wisej.Core.IWisejComponent)this).IsNew)
{
Eval(@”
this.getMenu().setPosition(‘right-middle’);

// this.getMenu().setOffset(…);
// this.getMenu().setPlacementModeX(…);
// this.getMenu().setPlacementModeY(…);

“);
}

base.Update();
}
}

HTH

/Luca

Hi Frank, I’m not trying to be too pushy, I’m sure you all have plenty of work to do.  But do you have any estimate of when this will be fixed?  We would like to begin using WiseJ in our production environment next month, but we cannot properly test until this is fixed.  Many of our users are external and are required to use IE.

Thanks!

These seem to be client side errors. Could be cause by the web server not responding with the requested resources.

Can you give me a link I can try? Send it to support at wisej.com.

When this error occurs, before restarting the app pool, can you please check memory and cpu? Also check in the Chrome console for errors.

Hi!
Some news or any workaround while new version is released?
Thanks in advance!

Thanks. I can reproduce. The problem is that you have two main surfaces: the Application.MainPage and the Application.Desktop. The page goes over the desktop, but then floating windows (Forms, MessageBox) are created  in the Window Manager on the Desktop which is now behind the MainPage. I’ll see if we can detect this case and use the page as the root surface as if the desktop wasn’t there.

When the Window which is now a Page is shown, the Page is automatically made the MainPage coveting the browser.

The reason Wisej creates the floating windows in the Desktop Window  Manager if there is a desktop is because you can create Desktop as a child of a Page (cannot have a Page as a child of a Desktop). This allows you to create a main Page with a “frame” and have a child desktop as a container for windows – and you can switch multiple desktops.

Try

Application.Desktop = null;

Or

Application.Desktop = null;

Application.MainPage.Controls.Add(new MyDesktop());

I was able to replicate it in a simple solution.  I created a new desktop application and then changed the window1 from a form to a page and it will not show.  I don’t see any errors.

Try MessageBox.Show(“Test”, modal:false). Also see if there is an exception on the server, in VS 2015/2017Debug->Exception Settings and then check the Common Language Runtime Exceptions. In VS 2013 is different: Debug->Exceptions, then enable Common Language Runtime Exceptions.

Also try Alert.Show(“Test”). See if it shows.

And of course, with F12 in Chrome see if there is a javascript error.

If you can send a link privately support at wisej.com or support at iceteagroup.com we can look at the client side and see if there is something we can spot.

Hi Tim,

we will provide the mixin for the icon today.

The issue with the different font size for the drop downlist will be fixed
and included in the next Wisej update.

See also here: https://wisej.com/support/question/combobox-drop-list-font-size-not-matching-set-font-size

Best regards
Frank

Any help on getting this working?  Also need to make the font in the dropdown list the same size as the control.

Thanks,

Tim Larson

Hi Andrew,

thanks. I have logged issue WJ-8274 for it.

Best regards
Frank

Hi John.

Static data is indeed shared among instances. You can use this feature to do amazing things. Have a look at https://wisej.com/support/question/bound-dgv-not-updating?sort=oldest 

There is this static collection. On one session, I updated the collection. As the collection is data bound, changes are pushed to the client, to all client sessions, each one running on a different browser. This is the kind of things you see on a desktop application but not on a web application.

This feature isn’t Wisej specific as it depends on web sockets. The point is it’s really easy to do it with Wisej.

We stressed test different scenarios in terms of memory (focusing on GC to make sure there are no leaks) and performance to optimize the JSON packets exchanged between client and server. We also have been running demo servers with live dashboard to monitor memory release and cpu peaks.

The dll size is not relevant since it’s loaded only once. What’s relevant is the total number of windows/pages and controls that are live at the same time. If your app creates a page with 300 controls, that’s your memory. If it keeps creating windows and never disposes them, that it will use more memory. We have very complex apps (practically impossible to build in ASP Net) with 1,000-2,000 controls all on screen at the same time. Then you have the issue of data sets and whether they are kept in memory or discarded.

The overall memory load is highly dependent on the application and it’s hard to tell you how many live sessions can a server of a certain size handle. With ASP.NET it’s the same, if an app saves a 10MB result set in the session then each session consumes at least 10MB.

The best way is to create X sessions as a baseline, see the memory used in Task Manager, then add Y more and divide the memory used difference by the session difference. If an average server component uses say 100 bytes (location, size, name, other properties), and you have 1,000 live controls (textboxes, buttons, listboxes, widgets, etc) you use 0.1MB. Then it depends on the data and whether a data set is kept in memory or not (like an ASP Net app would do). On average a medium size business app (which would be quite large for ASP NET standards) can easily use 1 to 5MB so you can have 5,000 to 1,000 live sessions on a 8GB server.

The most important thing for us is to make sure that all objects are fully collected and memory is released when a session is terminated or a component (like a form, page, window) is disposed.

HTH

Best,

Luca

Excellent information, thank you. Sorry to pepper you with questions…but back to the max. practical concurrent sessions question…has this been stress-tested?

My simple test application I’ve been playing with has the main window and another page, and the .dll that it compiles down to is around 17kb. I assume that that footprint plus wisej overhead plus whatever code is allocated during a session is more or less the memory footprint for each instance? A best practice would no doubt be to release memory you are no longer using…i.e. load, use, release. Is static data shared among instances?

If that’s the case, I don’t see a problem running running at least thousands of concurrent sessions on one box…does that seem reasonable?

Again, my apologies for the barrage of questions. (But I suspect other prospective customers would like to know the answers to these as well.) 🙂

-John

Most (if not all) ASP sites and apps that do something useful 🙂 use the Session object and persist in memory (or on disk/database, for the daring developers that have time to burn.) Wisej uses more memory because instead of recreating all the controls on each request/response it keeps a representation of the controls in memory. Wisej sessions also expire after a configurable amount of time. Wisej also detects user inactivity and has a keep-alive system to detect when the browser is closed or the connection is lost.

ASP.NET is based on an http request/response roundtrip and HTML concatenation on the server, like php. Outside of the request/response cycle, the server has no knowledge of the page or what’s on the browser, it only has the session and whatever objects the app places on the session. If an ASP.NET app places a control on the session it’s useless since it’s not “wired” to the page, it’s a dead control instance.

Wisej is a Real Time Web System from the foundation, so the server can update the client at any time without a request since it switches to websocket on the first load. So the server code can push updates to any control on the client at any time and from any thread. The server can even draw directly on the client.

Try the BackgroundTasks and CustomPainting: https://wisej.com/examples/

Or look at the ProgressCircle control here: https://wisej.com/extensions/

/Luca

Thanks for the fast response…I’m guessing the main issue with “website” development is that each instance of the application persists for specific amount of time before timing out from inactivity? Whereas ASP apps are transactional in nature? (I assume this is configurable?)

Has any stress testing been done to see how many concurrent sessions a typical server can accommodate with a reasonably-sized application?

Anyway…for me, the speed with which I can implement a site would trump any concerns unless it’s, say, an order of magnitude more expensive to run at scale. And even then, if the site is expecting only light-moderate traffic, no problem.