All Answers

I created a small project with the same results.

Can you attach the test case?

This is the second sample. 🙂

Hi Luca,

As you said when I use panel it works perfect. I will use that. But I found another bug I think. Take a look at my animated gif attachmet. When I am using userpopup problem is still alive. I will attach animated gif screen cast in second message.

Thank you.

Luca, thanks for the sample.  I believe I have found a solution, some very basic testing seems to show it works as we need it to, I’ll post back here if significant changes are needed for future developers.  Changes detailed below:

Default.json
“loaderTimeout”:  50  //Show the loader very quickly, 50ms

Application Main Form changed to implement IEventFilter:

private bool _inExecute = false;
public bool PreFilterEvent(WisejEventArgs e)
{
switch (e.Type)
{
case “interval”: //timer tick
if (this._inExecute)
return true; //don’t fire the timer event if the user is currently doing something. Too many of our controls/timers share resources
break;
case “execute”: //buttonclick
case “selectionChanged”: //selectedIndexChanged event.
this._inExecute = true;
e.Target.Event(e);
this._inExecute = false;
return true;//handled
}

return false;
}

I can’t reproduce. Try the app attached here: https://wisej.com/support/question/initial-test-on-usercombobox

If you are using a UserPopup as the control attached to the DropDownContol property that is probably the issue. The DropDown part is already a UserPopup. You can use any control, including  panels.

Hi,

thank you for fast fixing. 🙂

I think I found another one. This time, similar problem is seen at runtime.

At first click to usercombobox shows what I need (userpopup) and It seems work perfect. But after second click, it shows nothing.

I am working on the version 1.3.42.0.

thank you.

Got it. The timer control is fired by the client browser, it’s a simple javascript timer. I have seen timers used in VWG to handle updates for long running processes,  it’s not really needed with Wisej. One of the main purposes of a timer is to be able to fire asynchronously.

I understand the need not to change to much from VWG, we are having similar issues on our migration projects, at least for the first stage.

One option would be to register a global application event filter and process button click events and timer events and if the timer event is fired while processing a click event simply don’t dispatch it. I attached a small sample.

In the sample, the timer keeps firing while the process behind the button click is running. Check the checkbox, and the timer events are all discarded while the button (any button) is  processing a click.

There is no performance loss by filtering since that’s where all events are processed anyway.

This sample gives you full global control on how to synchronize events. The sample registers the Page as the filter, but you can use a single global object and register it when the app starts. You can register multiple filters too.

HTH

Best,

Luca

hi,

here the samples on which i’m working. the dayclic is fine but i would like to use some context menu on the right clic on the calendar or on a specific event.

For the drag and drop i use an external label which symbolize a preformed event : something looking like the https://fullcalendar.io/js/fullcalendar-3.2.0/demos/external-dragging.html

i also find usefull if you can add the scheduler (https://fullcalendar.io/scheduler/) (maybe is it all-ready done but i didn’t find it)

i’m sorry if my post looks like a Christmas wish 🙂

best regards

Stéphane

Hi Luca,

One problem I’m having is with timer controls.  If a timer fires while a user request is processing, we are getting occasional errors and unexpected results.  Without getting too deep in the details, if the timer and user request both try to use the same SQL connection, and the user request begins a transaction on that SQL connection, the request made by the timer control blows up and shows an error.

Obviously, we can rework our system to not share resources like that… but it could add a great deal of work to our conversion.  That’s why I asked.

Thanks.

Depends  on the call.

All PerformClick() methods are already protected, if you click a button and the app processes something and while processing you click  the same button again, the click is discarded (not even queued). But while the app is processing something, and the user resizes the window, or resizes the browser, Wisej has to process those calls, otherwise the UI will look frozen.

I guess the issue between two buttons, if the user presses button1, the app is processing something, and while processing the use presses button2, you need the click on button2 not to be processed? Or all click on the parent form, like changing the active tab or selecting another row, should be blocked?

One way would be to disable the container while processing, but it’s probably not a nice thing to disable/enable on each click. We could add a method or property to disable/enable pointer down/up events on the client area of a container without disabling it. Could also make it optionally automatic when clicking a button or a menu item. Would that help?

Hi Luca, thanks for the response.  I wonder, would it be possible to make each session synchronous, so each user can effectively only gets to execute one call at a time?  If this setting exists we could possibly use it to help simplify our VWG to WiseJ conversion.

Thanks

Try to increase

“sessionTimeout” and “responseTimeout” in Default.json.

The “Network Error – Cannot connect…” (or is it “Failed to connect…”?) may be from the initial load when the protocol is still http.

Please send a screenshot. Also if you enable “debug”:true in Default.json you should be more details in the browser console (F12).

Are you running on WebSocket or http?

With the fullcalendar you can drag & drop & extend existing event objects. When the event is dragged (or extended) you get the EventChanged event. You can also click anywhere on the calendar and get the DateTime of the click location in the DayClick event.

We can add the date/time information to some mouse events coming in from the fullcalendar widget. How do you drop the external label? Do you set the Draggable property to true? Or do you use DoDragDrop()?

Can you send a small test case?

Figured out the dlls in bin and Release where still 1.3.37.0 instead of 1.3.42.0. Deleting and adding the references, rebuiding or cleaning had no Effect. Deleted the references, deinstalled wisej, installed 1.3.40.0, updated to 1.3.42.0 and added the References. Seems now I really have 1.3.42.0.

Will make a deploy on the Server with the certificate in next days.

Best Regards

Corvin Meyer auf der Heide

Hi Luca,

Fixed in 1.3.42.

Thanks.

Hi,

It can be, I’m using a virtual machine where I do several tests

we update when we buy the final licenses 🙂

Thanks

Cristian

I can’t reproduce. It is the error that was referred in the other thread. Looks like your installation is pick up the previous wisej.js or it’s cached. I tried with FF and Chrome.

You can try this:

• Delete the browser cache
• Delete \windows\temp\Wisej\[app]\wisej.js (or simply delete all \temp\Wisej)

Let me know.

Got it. It was working in .23 because all bubbled events were dispatched, causing multiple keyboard and pointer events to go to containers since browsers bubble up events, when you clicked on a button, the click was also fired on all the containers all the way up.

Now the events are fired only to their original target. But we have composite widgets (like the ListView) where some event have to bubble. Logged as WJ-8111. Should be fixed quickly.

Hey Luca,

I have already installed .42 . Have read the other question and thought it may has another reason, so I opened a new one.

Best Regards

Corvin Meyer auf der Heide