All Answers

Hi Alaa,

Thanks for your reply!
The conditional compilation approach needs to add a lot of additional code as I did in the attached example.

The addition of a reference to a separate branch is not useful. I can not use the code from the external library in this case in a WiseJ form. Or am I wrong? Can you give me an example?

Best regards,
Yaroslav

Any updates?

It works well ! Thank you, best regards

Hi Huỳnh,

The Ctrl+N shortcut can’t be blocked in a browser, since it’s a native functionality!
The frame, or console, in this case, is the special Wisej.NET console that is part of the debugging system!

You can disable it by setting debug to false in Web.config file.

HTH,
Alaa

//

Hi Bernhard, Hi Yaroslav,

You can go with the Shared Project approach or include the .NET6 projects as part of the .NET6 dependency branch!

It can be done relatively easily on the project level with the new SDK Project Format too!

As an example:

<ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))'!='net'">
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj" />
</ItemGroup>

This way you can still have the NET48 dependency for the designer and continue to work on your project with no issues!

It’s a different take (and a much better one) on the conditional compilation approach!

HTH,
Alaa

Hi Frank,

Hi Yarslav,

we have the same problem. Our solution is to always ensure that we are using the designer using the .net 4.8 target but code everything else on the .net 6 target. Most of our .net 6 code is guarded by conditional compilation to ensure that the library is still able to compile on .net 4.6 and ensure that our controls can be used within the designer. This is a very annoying developer experience.

We are really looking forward for WiseJ designer support for .net 6 and 7. We also opened a ticket 5 months ago: https://wisej.com/support/question/drop-net-4-8-dependency

best regards

Bernhard

Hi Alaa,

Thank you!

I found the solution in another treat here in the forum.

Now everting works fine.

Kind regards.

We don’t have global behavior properties in the .NET side of Wisej. There are many on the js side but not really public and can change. For the wheel behavior, I can see two that we have test cases for: WinForms (identical to Wisej – no bubbling up) and WPF (bubbles up). Plain HTML in browsers is a mess and inconsistent.

I have attached a patch to the qx.ui.core.scroll.AbstractScrollArea js class. If you place it in a folder named /Platform or /Resources (https://docs.wisej.com/docs/concepts/embedded-resources#wisejresources-attribute) set it to Embedded Resource and uncomment [assembly: Wisej.Core.WisejResources(ExcludeList: “”)] in AssemblyInfo it will be bundled with Wisej js side and the scroll will behave like WPF. As an enhancement to Wisej.NET we have to add something to turn it off or on. Probably in options:{} in Default.json.

Same behavior in this web page. I have placed the mouse outside of the textbox I’m writing in if it has the scrollbars. Actually it’s quite terrible in a plain html page. Sometimes even with the cursor in the edit box with scrollbars the parent page scrolls, sometimes it doesn’t. Sometimes I have to click again in the edit box. Sometimes it gets stuck…

Tried with the super duper modern gmail browser app, same behavior.

Wisej works consistently. Maybe we can improve it and bubble the event up when the conditions are right, but it’s a low priority at the moment.

I see it now. So easy. 🙂 Thank you Frank!

Hi Yaroslav,

you should add the reference to the net6.0 branch instead of the net48 branch.

Best regards
Frank

Hi Jose,

There was a bug that’s now fixed in the latest 3.1.6-Preview-1 build of Wisej.NET!

Can you also try it out and check if it’s working now?

Best,
Alaa

Hi Yaroslav,

There was a bug that’s now fixed in the latest 3.1.6-Preview-1 build of Wisej.NET!

Can you also try it out and check if it’s working now?

Best,
Alaa

//

Hi Huynh,

this issue is fixed in Wisej.NET 3.1.5

Best regards
Frank

Hi Gabriele,

we actually found out that it is not only related to the automation mode. But good news: it´s fixed and now deployed in Wisej.NET 3.1.5.

Best regards
Frank

There is a workaround: if you put the controls inside a container the combobox are displayed.