[CLOSED] Checkbox always true in DirectMethod

Printable View

Feb 11, 2020, 2:19 PM
Jurke

[CLOSED] Checkbox always true in DirectMethod

Hi
I have found sort of an old bug coming back in this version, the checkbox is always true, in the direct event. Before the values where inversed, I can solve it with Delay=1. But maybe you should fix it, because its not so intuitive.

Code:

<%@ Page Language="C#" %><%@ Register assembly="Ext.Net" namespace="Ext.Net" tagprefix="ext" %> <!DOCTYPE html> <script runat="server"> [DirectMethod] public void showValue() { X.Msg.Alert("Status", String.Format("Value change event checkbox = {0}",chbDelete.Checked)).Show(); } </script> <html> <head id="Head1" runat="server"> <title>Checkbox</title> </head> <body> <form id="Form1" runat="server"> <ext:ResourceManager ID="ResourceManager1" runat="server" /> <ext:FormPanel ID="fpQuery" runat="server"> <Items> <ext:Checkbox runat="server" ID="chbDelete" FieldLabel="Click here !"> <Listeners> <Change Handler="App.direct.showValue();"/> </Listeners> </ext:Checkbox> </Items> </ext:FormPanel> </form> </body> </html>

Regards
Mikael
Feb 11, 2020, 3:47 PM
geoffrey.mcgill

Hi Mikael. It would be best to explicitly pass the checkbox value into the DirectMethod.

While the technique you are using should work on WebForms, it is not supported on MVC or the upcoming Ext.NET for ASP.NET Core. To provide the best forwards compatibility, explicitly passing the client value into the DirectMethod is best.

We will investigate why this does not appear to be working on Ext.NET WebForms.
Feb 11, 2020, 6:01 PM
fabricio.murta

Hello Mikael!

First of all, thanks for the test case, it'll hopefully make it clearer to understand and provide you with a solution on the matter!

The problem we're facing here is a "race condition", where depending on who is faster, the state seen at code behind will be one or another.

The thing is, the change event is triggered during the change, and not explicitly after nor before the change occurred. Relying on the state of the checkbox is, as you may have noticed (as the delay changed the result you get in code behind), unreliable. In this case, you should rely in the event's transmitted values which, at the time the event is triggered, is not really related, or cares about, the current state of the component being changed.

That said, I have adapted your example with a proper way to handle it:

Code:

<%@ Page Language="C#" %><%@ Register assembly="Ext.Net" namespace="Ext.Net" tagprefix="ext" %> <!DOCTYPE html> <script runat="server"> [DirectMethod] public void showValue(string newValue, string oldValue) { X.Toast(String.Format("Value change event checkbox. from {0} to {1}", oldValue, newValue)); } </script> <html> <head id="Head1" runat="server"> <title>cbCb: CheckBox at CodeBehind</title> </head> <body> <form id="Form1" runat="server"> <ext:ResourceManager ID="ResourceManager1" runat="server" /> <ext:FormPanel ID="fpQuery" runat="server"> <Items> <ext:Checkbox runat="server" ID="chbDelete" FieldLabel="Click here !"> <Listeners> <Change Handler="App.direct.showValue(newValue, oldValue);"/> </Listeners> </ext:Checkbox> </Items> </ext:FormPanel> </form> </body> </html>

As you may have noticed, I have passed to the direct method the old and new values the checkbox event informed. Direct Methods aren't related to the actual event, so we need to "pass" what we need, as we would with a normal function/method call. It doesn't have an "associated event" to it. A Direct Event would be another story.

You may now be asking "how did they know there were newValue and oldValue available when calling the direct method?

If so, the answer would be either by:
- looking at the generated page, /extnet/extnet-init-js/ext.axd?<...> in developer tools' source browser, and finding the line with the direct method call; in this case: fn: function(item,newValue,oldValue){App.direct.showValue(newValue, oldValue);}; setting ResourceManager's SourceFormatting="true" and/or adding a debugger; and letting browser stop by to fiddle a bit, helps;
- Opening this example Events > Listeners > Arguments, choosing the component and event you want to know arguments of.

Hope this helps!
Feb 12, 2020, 8:56 AM
Jurke

Hi
Thank you for the explanation, I understand what you mean.
I have, in my projects, made a lot of DirectMethods that read propertys of various ext: components. Does this mean that my approach is a bad idea for future versions of Ext? It seem like a lot of work to always pass all the values into the DirectMethod.

Regards
Mikael
Feb 12, 2020, 2:47 PM
fabricio.murta

Hello Mikael,

It is not always a bad idea. In the case we have here, it would not work well as described but, for instance, if you have a form, and call a direct method to check the validity of the filled fields before submitting, it should be okay, as you won't have any field "in the middle of something".

Generally speaking, you should not have issues like the one with the change events. At the same time, we can't say this is the only and only case where relying on components' current state is unreliable.

In another point of view, if you are within an event from a component and want to handle something from it, it is best to reference parameters passed to the event than the component's "public" state (what you can get externally from the component).

Yet in another aspect, if you are using a Listener to call a direct method, you may instead want to switch to a Direct Event. In case you need mixed client-side and server-side actions, direct events has several points you may add scripts to handle pre- and post- calls. To name them:
- Success: call made, server returned with success,
- Failure: call made, server returned with failure/exception,
- Completed: call made, server returned, regardless of success/failure,
- Before: right before call being made, returning false will prevent the call from happening
- After: right after the call, before the server returns the result

So, in short, I'd say it is safe to keep the direct methods as you have; keep an open eye for failures like you witnessed with checkboxes. For new pages, use Listeners when all you need is to perform client-side javascript tasks, and DirectEvents when you have tasks that require the server to be queried.

Direct methods still have their value, especially in readability, as you call them passing arguments as you would to a JavaScript method, and it is more intuitive to another programmer as to what is passed. Direct events requires passing parameters as ExtraParameters which get encapsulated in the event object passed to the server, being less evident they are there when developing.

Hope this helps!
Feb 13, 2020, 6:57 AM
Jurke

Thank you again for a very good explanation. I have used Ext a long time, (since Coolite) and was under the impression that DirectMethods where faster than DirectEvents, maybe the where before. I assume this is not the case any more. Then its no problem to use DirectEvents in the future.

Regards
Mikael
Feb 13, 2020, 11:37 PM
fabricio.murta

Hello Jurke. You are probably right about the performance as I didn't really pay much mind for it while considering your answer. Nevertheless, nowadays internet and computers' speed has increased so much the difference gap has just become negligible in normal cases; so I still believe you're good with DirectEvent where they are more useful.

Direct methods and events should be avoided when you can just do simple and recurring tasks at client-side; something that has not improved thru time is the network latency and the possibility of a network failure causing server side calls to take a considerable amount of time (during a network unstability event, for instance).

I'll be marking this thread as closed now. We won't lock it up so if you ever have questions again following this checkbox issue, feel free to continue the thread.