开发者

Bogus (Yet Crippling) "[WebElementId] is not declared" Error In VB.NET

开发者 https://www.devze.com 2023-01-07 18:04 出处:网络
So I have the error mentioned in the title when I try to build my web site through the file menu. The code that causes this is below (JavaScript that appears in the body tag):

So I have the error mentioned in the title when I try to build my web site through the file menu. The code that causes this is below (JavaScript that appears in the body tag):

            if(editedRow != null)
            {
                var SundayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_SunLocale.ClientID %>");
                var MondayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_MonLocale.ClientID %>");
                var TuesdayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_TuesLocale.ClientID %>");
                var WednesdayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_WedLocale.ClientID %>");
                var ThursdayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_ThursLocale.ClientID %>");
                var FridayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_FriLocale.ClientID %>");
                var SaturdayLoc = $find("<%= FieldOpsScheduler_ctl00_ctl05_RCB_SatLocale.ClientID %>");

                if(currentCombo == "OFF" || currentCombo == "OFFICE")
                {                
                    if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_SunActivity")
                    {
                        SundayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_MonActivity")
                    {
                        MondayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_TuesActivity")
                    {
                        TuesdayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_WedActivity")
                    {
                        WednesdayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_ThursActivity")
                    {
                        ThursdayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_FriActivity")
                    {
                        FridayLoc.disable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_SatActivity")
                    {
                        SaturdayLoc.disable();
                    }

                    sender.hideDropDown();
                }
                else if(currentCombo != "OFF" && currentCombo != "OFFICE")
                {
                    if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_SunActivity")
                    {
                        SundayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_MonActivity")
                    {
                        MondayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_TuesActivity")
                    {
                        TuesdayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_WedActivity")
                    {
                        WednesdayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_ThursActivity")
                    {
                        ThursdayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_FriActivity")
                    {
                        FridayLoc.enable();
                    }
                    else if(rcbID == "FieldOpsScheduler_ctl00_ctl05_RCB_SatActivity")
                    {
                        SaturdayLoc.enable();
                    }

                    sender.hideDropDown();
                } 
            }

Now what's really weird (and perhaps is an underlying cause of this occurring) is that when I delete the above code, exactly half the errors pointing out those web form element ID names go away. However only half -- not all of them, which doesn't make sense seeing as I got rid of all parts of the JavaScript code that ask for the web form elements' IDs.

After deleting all relevant JavaScript and double-clicking the remaining seven error messages in VS2005, they all take me to the very first line of code in the page, which is this:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="DistrictSchedule.aspx.vb" Inherits="FieldOperations_DistrictSchedule" %>

Myself nor my coworker knows what the deuce is going on. When I get rid of half of the errors, at least the page will execute. However it all SHOULD work, judging by the code..

Additional Error Info: I should mention that those web form element IDs that I'm trying to find exist ONLY when my RadGrid is in edit mode, so it would make sense that they're not originally there to begin with. Regardless, this should NOT be causing a site-crippling error, although for whatever reason it is. Lastly, the specific lines throwi开发者_开发百科ng the error are the ones utilizing $find, and the lines utilizing the vars that $find gets values for throw the error too.

Whoever out there who can tell me what is going on would be a MAJOR help. I thank you in advance.


So I got my bright-idea for a fix to this when I randomly browsed some other page looking for information regarding find() and Telerik. I noticed in some cases you have things like:

var whatever = $find("<%= SomeControlIDDeclaredServerSide.ClientID %>");

And in other cases you have things like:

var whatever = $find("SomeControlIDAsDisplayedOnWebpage");

Turns out, these two quite similar lines of code are not interchangeable, though at first-glance one might think they are. Specifically what got rid of ALL of these utterly-annoying errors in my case was to use the second line without the brackets and percent signs.

My theory as to why line two works in my case and not line one, is that when selecting Compile/Build Website, if you utilize code like line one, the compiler expects your object to be created via markup syntax on the .aspx page immediately at runtime. In my case, the "FieldOpsScheduler_blahblahblah" was being dynamically created when my RadGrid gets put into edit mode (so, not immediately at runtime).

Anyway hopefully my experience will help someone out there who runs into this problem or a similar one.


Glad you found your own solution. For further clarification, here's what's happening.

<%= %>

The above is shorthand for Response.Write. So, when you use the following line of code:

var whatever = $find("<%= SomeControlIDDeclaredServerSide.ClientID %>");

You are telling your ASPX page to get the ClientID of your server-side control and then output that ID to your JavaScript when the page is processed, resulting in something like this on the rendered page:

var whatever = $find("ctl00_ctl05_SomeControlIDDeclaredServerSide");

This is often used when doing JavaScript programming with ASP.NET to get the client-side HTML ID of server-side controls because ASP.NET can dynamically adjusts HTML IDs at runtime. This code ensures you always have the correct ID in JavaScript regardless of ASP.NET container naming adjustments.

If your client ID is static (what you set at design-time is what renders to the page), then you don't need the ClientID look-up and can instead write this:

var whatever = $find("SomeControlIDAsDisplayedOnWebpage");

Where "SomeControlID..." is the actual HTML ID of the control you're targeting. The JavaScript $find method will look for that HTML ID directly and get a reference to the HTML object.

Hope that helps with the "why."

0

精彩评论

暂无评论...
验证码 换一张
取 消