All Answers

For the cookies issue, just had a similar request. I think the problem is that the cookie is set using http-only then Wisej cannot remove it using the WebSocket response. But you can use the Http context in the first request since it’s http.

This executed in Program.Main deletes an http-only cookie.

System.Web.HttpContext.Current.Response.Cookies.Add(
new System.Web.HttpCookie(“Test”) { HttpOnly = true, Expires=DateTime.Now.AddDays(-1) });

Post an example of blockly in an iframe with Wisej that doesn’t work and we can help you. Blockly is not written very well and it doesn’t work inside divs with certain css styles. I wasted a lot of time trying to understand what they are doing wrong in jsfiddle but gave up.

The bubble is too high, with reference to the associated control.

“Wisej can use any third part javascript library as is.” but Blockly 🙂

The cookie should be deleted, unless the url doesn’t match. Can you reproduce in a small test case?

In Javascript in Chrome (F12) put a break in Wisej.Core.setCookies() and see if it tries to set the cookie to delete with a date of “; Expires=Thu, 01 Jan 1970 00:00:00 UTC” which is the only way to delete cookies.

In alternative try Application.Browser.CookieStorage.RemoveValue(“cookie name”); In this case the break on the client can go to Wisej.Core.removeStorageValue().

Thank you Luca!

You nailed it.

Hi Levie.

Trying to find a solution to this, I arrived at the DevEx documentation page where they instruct us to use the InitializeCulture in order to be able to set the Application Culture ( https://docs.devexpress.com/AspNet/12050/common-concepts/localization/satellite-resource-assemblies ). In the Runtime session of this page there is a sample on how it should be done. However, we don’t get the InitializeCulture in our Pages/Windows. Would there be a way to do something in order to follow their instruction in a Wisej fashion?

I think the fact that if we put a break point at the time we set the Culture and this makes it work is a good clue, for you guys, of what could be going on.

PS: this is the Method mentioned: https://docs.microsoft.com/pt-br/dotnet/api/system.web.ui.page.initializeculture?view=netframework-4.8#System_Web_UI_Page_InitializeCulture

Hey, this looks like it is going to be one of those tricky ones… at least for me.

I spoke too soon. It works at times, it doesn’t in others. I even put the CurrentCulture setting in all events (PreInit, Load and DataLoading) and sometimes, even if set to Portuguese, for example, it comes in English. Then, I put a break point at the time I set the CurrentCulture and it worked just fine. I guess the ASP.NET thing of talking back and forwards has something to do, but why would we loose the CurrentCulture settings?!

I tried using Thread.CurrentThread.CurrentCulture instead of the Application.CurrentCulture too, but same results. I think I have a problem… 🙂

Hi Levie.

Success!

Tried the Load, didn’t work. Tried the PreInit, it worked perfectly.

Thank you.

Hi Huỳnh,

We’re looking to have a a release of 2.5 available by the end of June this year.

Best,

Levie

Hi Levie.

Thanks for the reply!

Yep, I am doing it in the Program.Main and then later if the user chooses a different language. It is all fine with my Wisej controls, the thing is with the DevEx Dashboard wrapper. The first Dashboard I open comes properly localized, after this one, all others are not localized anymore. It is like the “main thread” is respecting the CurrentCulture and the first Dashboard is opened in it, but then the others come in a different “thread” where CurrentCulture hasn’t been changed.

Yes, I am using the latest from Wisej.

Thanks.

Ivan

Hi Ivan,

You can do it in Program.Main and it should work correctly. I know you had some issues with setting the localization before, any chance we can get a small sample demonstrating the issue?

Are you using the latest version of Wisej?

Best,

Levie

Blockly doesn’t work. The integration is easy but blockly dagging and menu fail to work when it’s inside a div that us a bit more complex than <div>. There is nothing we can do. You need to put it in an IFramePanel.

Thank you!

It works fine!

Please help with blockly 🙂

Thanks for the response Levie.

I run your attached sample, but the result is the same. I can’t stop or turn off the camera.

I have run your example 4 minutes ago, I left the application in the background and the camera is still on. If I kept using the application, it would keep running all the time.

The need to use dispose on the camera, is because we inferred that performing this action would turn off, but it is not.

I think there should be an option to turn the camera on or off whenever you want, and not let it stay on for as long as you close the browser or leave the application.

Thanks.

I’ve logged the exception that’s thrown as issue #2606. A fix will be available in the next build!

Thanks for your help!

Levie

Hello,

I’ll need to look and see why that error is thrown. It shouldn’t be, but…

You don’t need to Dispose the Camera or BarcodeReader to turn off the scanning. The BarcodeReader component has a property “ScanMode” that when set to AutomaticOnce will only report the first Barcode it finds.

You can then reset this and use it again by calling BarcodeReader.ResetScanner().

Please give the attached sample a try and let me know if you run into any issues with it. It demonstrates the different ScanModes.

Best,

Levie