All Answers

Hi Alex,

I’ll address the questions individually:

• TabIndexChanged is the event fired when the TabIndex property is changed and should be hidden in Form and Page. This is bug WJ-7403. There are other inherited events that have to be hidden. They are still functional when the form is used as a child control, but should be hidden in the designer.
• MdiChildActivate should be fired but it’s not: bug WJ-7402.
• We don’t have the cascading view for mdi children. The tabbed mdi was one of the first things we had to add to VWG when we used it on projects, every customer asked to get rid of the mdi cascade view. It can be added, but it’s not on the list now.
• VWG had only one window class Gizmox.WebGUI.Forms.Form. It acted as a page when assigned to Global.Context.MainForm. Otherwise it was a floating window. It could also be minimized, causing the creation of a simple taskbar with the minimized forms. In Wisej we have Wisej.Web.Form which is always a floating window (unless created as a child control or an mdi child – like in VWG or WinForms), the Wisej.Web.Page which is always a single page and always fills the browser, and the Wisej.Web.Desktop wich can fill the browser when assigned to Application.Desktop or behave as a child control. The desktop is the only control that can handle minimized forms. Otherwise they are simply hidden and you have to manage them depending on your code. We separated the classes to avoid issues with the caption, buttons, tools in the caption, borders, etc.

And the last answer, related to the more important question is:

The close functionality is already included in the TabControl. You can enable/disable it for the individual tab setting the TabPage.ShowCloseButton property. And should be automatically there for the tabbed mdi. It can also be turned on/off in the theme. And I just noticed that now is not visible anymore. Logged as WJ-7404.

So you got 3 bugs with 1 post!

Thank you.

Luca

Hi Alex,

The ToolStrip system is a relatively large subsystem in WinForms. The “traditional” winforms toolbar that we have now in Wisej covers most of the functionality in VWG and covers all of the toolbar functionality in Winforms. Including drop down menus, icons, menu separators.

The ToolStrip subsystem will be implemented for sure partially by the release date and most likely completed right after.

You can see the widgets that are available to us here: http://demo.qooxdoo.org/devel/demobrowser/#widget~Menu.html

With Wisej we extend the available widgets, integrate them with our themes, and build the server side representation, designers and editors. The server side, designers and editors are the time consuming part.

Best,

Luca

Hi Nic,

My usual IDE is VS2015. I guess VS2012 is yours. Usually I close VS2015 before installing or removing Wisej. Since the usual IDE is always open, I can’t exclude I forgot to close it on some occasion. I wonder if that’s what caused the issue.

Interesting you should say that because I have the same issue with toolbox duplication in VS2012. I can’t quite put my finger on when or how it happens but the icons do seem to keep duplicating. I’ve also noticed that the chart.js extension is never included in the toolbox after an update. I always have to go and manually add it back in.

Nic

All the classes that we need are available in mono. The question is if they are reliable and if they perform the same as in .NET. If they don’t, we can rewrite them. It’s a question of time, effort, and benefit.

Technically it’s 100% sure that Wisej and wisej apps can run on linux. When and with how much effort is what I cannot answer yet.

Our target platform for the release is Windows/IIS.

Best,

Luca

If I understand correctly the Mono compatibility page, Mono fully supports .NET 4.5 and ASP.NET.

Does Wisej needs System.Windows.Forms at runtime? If it does, I guess this is incompatible with Linux.

Hi Mark,

Found the reason why it doesn’t work with Cassini and have logged an enhancement for the next update: WJ-7397 “Add support for classic pipeline”.

Cassini only works with the older classic pipeline so you need to configure web.config like this:

<system.web>
  ...
 <httpHandlers>
 <add verb="*" path="*.wx" type="Wisej.Core.HttpHandler, Wisej.Core" validate="false"/>
 <add verb="*" path="*.wx/*" type="Wisej.Core.HttpHandler, Wisej.Core" validate="false"/>
 </httpHandlers>
 <httpModules>
 <add name="Wisej" type="Wisej.Core.HttpModule, Wisej.Core"/>
 </httpModules>
</system.web>

However, without the WJ-7397 this will still not work because Wisej checks for an incoming WebSocket upgrade and the System.Web.HttpContext implementation throws a PlatformNotSupported exception instead of false…

The good part is that it works with  the asynchronous IHttpHandler.

For the license, Joe Meyer will contact you to get some more info and provide the OEM/ISV licensing model.

About the self contained exe, the plan is (after the release) to use http://sensaura.org/pages/tools/iotweb/ together with a Wisej library and a boxing tool that can optionally virtualize everything in a single self-contained executable capable of displaying it’s own UI (Wisej would act as a desktop app) and to serve external users as if it was a server box.

Linux support may come later, probably much later. We don’t know the technical barriers yet.

Best,

Luca

Luca, you are right! Cleaning the solution, exiting VS and reopening it did the trick. So it turns out it was a caching problem.

Many thanks, Alex

I can see from the stack trace that the assembly loading is triggered by Wisej inspecting the referenced assemblies for resources. We’ll wrap that in a try/catch and rethrow a more meanigful exception with the name of the assembly that failed.

Hi,

Continuing … I used the NuGet manager for the solution to install the log4net package to the Wisej project. Now the designer does not complain anymore for missing log4net, but another 3rd party package installed in other projects in the solution. Very confused …

Alex

Thanks Luca,

I’ve sent you a copy of the extension.

Nic

Sounds good. Send the project, I’ll be more than happy to take a look.

Hi Luca,

I’m almost there. I’ve managed to get everything I want into the gage control but I have one problem left:

Somehow the labelColor property means that the labels are invisible on the control unless I actually specify a color. I have not changed this property from your original implementation so I’m at a loss.  I’m not really sure how your color defaults work for themeable colors.

I’m happy to return the enhanced extension to you for publication. I would just like to understand where I’ve gone wrong on color.

Thanks

Nic

Hi Luca,

“We are also planning an extension that would turn a Wisej web application into a single standalone .NET executable …”

This would be a massive plus to WiseJ (IMHO), for our generalized use case we would need this to also run on Linux (we standardize around Debian, obviously utilizing mono currently but I would suggest keeping an eye on .NET Core as this is nearly ready to run most ASP.NET applications [apparently]).

Re: licensing, we already license other development solutions in the way you describe, so hopefully we can sort something out.

Please can you forward the transcript of this conversation to your sales and ask them to get in touch with me on the same email I am using here to post (I assume you have access to it?).

Regards,

Mark

Hi Mark,

We will have an ISV license with unlimited activations. It’s similar to an OEM license. We already have several ISVs using our other framework with site development license and unlimited distributions. When an ISV is deploying to 4000 servers we know very well that we cannot sell 4000 licenses.

The cost is a flat fee that is negotiated individually. The ISV license is a single key that the ISV can embed in their distribution. It can be unlimited or capped at a number decided by the ISV.

If you would like an early quote in order for you to determine if Wisej is worth the effort I’d be more than happy to have our sales guy contact you.

Best,

Luca

Hi Luca,

Thanks for the responses.

Your technical response to the embedded webserver makes sense. I’m not sure why it doesn’t work with Cassini then, strange.

However the technical aspects would be overshadowed by the cost negatives of the current licence costs anyway as it stands. The end units in question are planned to be in the hundreds if not thousands and they are low cost. With the webserver part of the units operation being a “nice to have” setup/configuration tool, there is no way the licence cost per unit could be justified.

It’s a shame, as Wisej looks perfect to perform the webserver task for these units. To put it in context, we would rather have 100 servers limited to 1 concurrent user than 1 server limited to 100 concurrent users.

Anyhow, thanks again for your time.

Mark

Forgot the question about the license model. An embedded web server is still a server instance in the license model. Each server instance will need a server license, regardless of the number of applications and CPUs.

https://wisej.com/support/question/licensing-model-and-costs

Best,

Luca

Hi Mark,

Wisej intefaces with the web server using IHttpHandler and IHttpApplication. However, the module IHttpApplication can be omitted if you don’t need to use urls without the extension.

Basically if VWG was working then also Wisej should work. Unless the web server doesn’t support the async IHttpHandler, which is the same used by VWG in their later releases.

For the short run I will try Cassini/Ultidev and see why it doesn’t work. It should and most likely it will soon.

After the release we are planning to look into FastCGI, Apache mod or mod_mono, and Linux. We are also planning an extension that would turn a Wisej web application into a single standalone .NET executable (probably using Cassini or another embedded WebSocket server)

Best,

Luca