writer.RenderBeginTag( HtmlTextWriterTag.Table ); ... ... ... } I want to set the TOP and LEFT position of the style property for a table I'm rendering. This presents two problems: 1. In the designer, the table isn't at, say, left:100, top:100 of the
page, but rather left:100, top:100 of wherever the control is dragged in the designer. When the control is rendered at runtime, everything is positioned fine. How do I coordinate my control's TOP and LEFT with the drag position in the designer? 2. This is
much more important. In every browser but IE, the style attribute doesn't render at all thus everything's positioned wrong. This REALLY sucks. It messes up my entire plan. Is this a case of VS.NET doing "smart rendering" for a specific browser and wrecking
my code?
Hi, for your second question: ASP.NET treats other browsers than IE like downlevel browsers and will render other html to these browsers. You can alter these settings in the machine.config or maybe somewhat wiser: override them in the web.config of your current
project. Some more information can be found here:
ASP.NET Server Controls and Browser Capabilities Grz, Kris.
Read my blog | Twitter Working with Azure, chatbots, ASP.NET MVC, Web API, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Cool link! Unfortunately the settings file idea won't work because, ideally, I'd like this to be a distributed control that doesn't rely on settings tweaks. Do you know if there are methods I can override in my control to highjack the ClientTarget detection?
Can I simply turn this setting off for my control alone? For now I've simply reverted to the .Write( "string" ) function to manually render tags with concatenated attributes, but it seems inelegant.
I'd strongly advise against the way you're creating this control ... it works
against the ASP.NET server control model. First, your control should inherit System.Web.UI.WebControl. That way, it will inherit the design-time functionality of the standard ASP.NET controls. Second, properties such as Top and Left should not be hard-coded
into your control's Render method. Rather, if your control inherits System.Web.UI.WebControl, then this base class will take care of rendering such style attributes. Third, your control should not be specifying its CSS class. By all means it can set is own
Style properties, but not by way of a custom class. Fourth, it is not the role of a server control to establish the Page's ClientTarget. Rather, that is the responsibility of the Page designer. If you're serious about creating a distributed control, then these
are all very important considerations. Going against the ASP.NET server control model creates unnecessary work for you, and risks breaking Pages on which your control is placed (very poor experience for your potential customers). MSDN provides a huge amount
of information on
Developing ASP.NET Server Controls.
> Why on earth did this get moved to "Web Forms"? This has NOTHING to due with forms and EVERYTHING to do with Server Control creation. Bad mod! Other than the existence of a method named Render, your original post holds no suggestion that you're talking about
your own custom server control, but rather suggests you're simply trying to position a control in VS.NET. Further, your Render method includes code that absolutely does not belong there. In fact,
not a single line of your code belongs in a web control's Render method ... most of that code belongs on the web form. (Bad developer!) If you find your post moved into an inappropriate forum, perhaps you should be questioning the lucidity of your description
and the relevance of your code, rather than criticising the voluntary efforts of the mods who
each process thousands of posts each month?
"First, your control should inherit System.Web.UI.WebControl. " Um, duh. "it is not the role of a server control to establish the Page's ClientTarget." I know, that's why I'm asking if I can do something about the "smart rendering" at a control level. The methodology
I'm using isn't reflective of an ignorance of server control development practices per se, but of rather unique requirements that have to work around the limitations of the server control framework. Let me explain. What's going on is that I'm developing a
cross-browser compatible drag and drop system similar to ASP.NET 2.0 WebParts but more extensible and not only limited to IE. It's based on scripts that, for example, flag a draggable element by CSS class. Additionally, the only portable method I could find
for cross-browser draggability (if that's a word) is to use absolute positioning and STYLE. Therein lies the rub. Firefox, Netscape, and Mozilla all respond well to absolute positioning in the STYLE element, but the Framework downlevel-renders my control such
that the information I need is lost. Basically it breaks everything but IE. That leaves me looking for the "proper" way to do what I want to do because, I must admit, what I'm doing feels like a hack and I hope there's a better way. That's why I was trying
to get feedback from some Server Control experts. PS- Cool link. Up to now I was basing everything on the MS Press book, "Developing Microsoft ASP.NET Server Controls and Components" and some googling.
> I'm asking if I can do something about the "smart rendering" at a control level Every control provides access to its container page via its
Page property. Given that, in your control's Init method, you should be able to set the Page.ClientTarget property.
That should theoretically stop any down-level rendering that's frustrating your efforts. Of course, another control or the page itself could always undo this ... Other than that, I believe the only other option for a server control is to hard-code the required
styling directives, as you're now doing. However, it's still the wrong thing to do. You're creating a cross-browser drag-and-drop system. For this to work, it requires reworking the Page itself. There is simply no way in heck that your cross-browser WebPart-type
control will work on a standard ASP.NET Page. There's simply too much IE-centricity built into the standard ASP.NET Page. I have created a library of controls that render a valid XHTML page. But to achieve this required creating a new Page control, too. For
example, what happens when your control is dragged and dropped? At some point, a postback must occur. The __doPostBack script uses document.all as its method of branching its script. This won't work for the likes of Opera, Mozilla, Safari, etc (they will be
wrongly identified as Netscape 4). Additionally, your WebParts-like system will presumably be using ECMAscript to "attach" client-side events to your controls. The standard ASP.NET page only gives you the RegisterStartupScript method. However, this injects
the script in a non-ideal location on the page ... I would not be surprised if it would not work in the newer browsers. So you see, a cross-browser WebParts system cannot be achieved by the WebParts themselves ... they need to be placed on a reworked Page.
And, given that, it's no longer necessary for your controls to worry about down-level rendering ... they can rest easy knowing that they're to be placed on an updated Page, and that Page will force up-level rendering. Here's the approach I'd recommend. Forget
ASP.NET for the moment. See if you can create an HTML page (with its CSS and ECMAscript) that achieves cross-browser drag-and-drop functionality ... a page that can be opened by any browser and works in the way you want. If you can get that page to work, you
can then rework it as an ASP.NET system. Some parts of your resulting HTML will need to be controlled by an updated Page, while other parts can be thrown into your server controls. Because if you start and stay at the server control level, my guess
is that you'll never get a cross-browser drag-and-drop system working ... I simply don't think it can be achieved by custom server controls on a standard Page. > Get a sense of humor, homeboy. You're taking things too personally. I'd had a bad day ... and
then having my voluntary efforts criticised pressed my grumpy-button.
"I'd had a bad day ... and then having my voluntary efforts criticised pressed my grumpy-button." I guess it did sound a bit harsh. While the decision to move the post still confuses me I didn't really mean any harm by what I said. Sorry, man. "See if you can
create an HTML page (with its CSS and ECMAscript) that achieves cross-browser drag-and-drop functionality ... a page that can be opened by any browser and works in the way you want." Did that. "If you can get that page to work, you can then rework it as an
ASP.NET system. Some parts of your resulting HTML will need to be controlled by an updated Page, while other parts can be thrown into your server controls." Besides the little hiccups (like the one I needed help with), I actually did manage to fit everything
into a server control architecture. The dragging works like a dream and is portable, and I'm now integrating manager classes that handle interaction with other elements. I'm keeping my exact methodology a secret, but suffice it to say it's working well and
it should be pretty cool when I'm done with it! "I would not be surprised if it would not work in the newer browsers." Is there a risk that the current methods of registering client javascript won't be compatible with browsers in the future, or are you saying
this is more a concern at present? RE: Page control subclass What you did sounds pretty interesting. Do you know of any good links for the subject? Oh and thanks for responding. I really do appreciate your contribution to the ASP.NET community. I'd be lost
without the occasional help of this forum's all-stars.
> Is there a risk that the current methods of registering client javascript won't be compatible with browsers in the future, or are you saying this is more a concern at present? As you'll know, the RegisterStartupScript javascript will be placed immediately
before the closing </form> tag. My concern is the DOM (so so important to ECMAscript) is not complete by the time such registered startup script is run. Many control authors allow such registered startup script to
actually run there and then ... targetting an incomplete DOM. For example, by injecting the following: CreateWebPartManager('HiddenCopyLayer'); document.zoneObject = null; zoneObject = __wpm.AddZone('left', 'left', true, true, 'Blue'); zoneObject.AddWebPart('WebPart1',
'WebPart1Title', true); zoneObject.AddWebPart('WebPart2', 'WebPart2Title', true); zoneObject.AddWebPart('WebPart4', 'WebPart4Title', true);
While this may work in IE, it may easily fail in newer, stricter browsers. Just as importantly, some of the WebParts may be placed on the page after the server <form>, so such initialization script would fail in
any browser. Of course, this can be remedied by using either RegisterStartupScript or RegisterClientScriptBlock to inject code such as the following:function MyInit() { CreateWebPartManager('HiddenCopyLayer'); document.zoneObject = null; zoneObject
= __wpm.AddZone('left', 'left', true, true, 'Blue'); zoneObject.AddWebPart('WebPart1', 'WebPart1Title', true); zoneObject.AddWebPart('WebPart2', 'WebPart2Title', true); zoneObject.AddWebPart('WebPart4', 'WebPart4Title', true); } window.attachEvent("onload",
MyInit); That potentially solves the problem of an incomplete DOM when the initialization script runs. But what if another control developer also injects similar window.attachEvent code? I don't think you can have more than one function attached
to a DOM event. Another problem is that not all pages use a server side form tag at all. Yet the standard ASP.NET Page
requires such a form tag in order to inject any scripts registered by server controls. So, you'll see why I think that when developing a control system that targets the entire page (in contrast to typical server controls which concern themselves only
with their little piece of HTML), it is wise to implement your own Page, too. Give your system the level of control it needs, rather than fighting against the standard Page's limitations. And if you're developing a cross-browser system, it seems pointless
throwing it onto a page that is IE-centric in every other respect. A cross-browser server control collection deserves a cross-browser Page. > Page control subclass. What you did sounds pretty interesting. Do you know of any good links for the subject? Well,
when I started, the following was my guide:
Valid XHTML within .NET However, my own Page quickly developed to include
MetaBuilders MasterPages control. You see, that control requires a custom Page, too ... as some controls simply
must live on a custom Page ... which is why I think it would be completely permissible for your server control collection to require one, too. I also hate the standard limitation of a single <form> tag ... so my custom Page allows for multiple forms,
supporting both post-away and postback actions. I haven't yet added the following to my Page class, but I've bookmarked the following article about a custom Page class:
Build Your ASP.NET Pages on a Richer Bedrock
Thanks, Kris. I hadn't seen that article before. To be honest though, I don't think any of the provided options are truly valid. All approaches other than a custom server form are simply hacks. It's a custom server form that's required. Yet, I'm pretty sure
there's a major fallacy in the way he creates a custom server form. I wouldn't recommend anyone doing it the way shown. I know that will come across as highly arrogant on my part. But for anyone attempting to support multiple forms on their ASP.NET pages,
I think the following points the way:
Multiple Forms and Non-PostBack Forms While the above refers to a commercial server control, it really isn't that hard to create a similar one. Nor is it hard to fork over $50 and get access to all of Paul's controls :)
Member
10 Points
580 Posts
Setting Top and Left In Style: 2 Problems
Sep 03, 2004 04:17 AM|BoulderBum|LINK
protected override void Render(HtmlTextWriter writer) { writer.AddAttribute( "class", "ccDrag" ); writer.AddStyleAttribute( "TOP", intImageTop.ToString() + "px" ); writer.AddStyleAttribute( "LEFT", intImageLeft.ToString() + "px" ); writer.AddStyleAttribute( "POSITION", "absolute" ); writer.AddAttribute( "id", this.ClientID + ":tblDragImage" ); //
writer.RenderBeginTag( HtmlTextWriterTag.Table ); ... ... ... } I want to set the TOP and LEFT position of the style property for a table I'm rendering. This presents two problems: 1. In the designer, the table isn't at, say, left:100, top:100 of the
page, but rather left:100, top:100 of wherever the control is dragged in the designer. When the control is rendered at runtime, everything is positioned fine. How do I coordinate my control's TOP and LEFT with the drag position in the designer? 2. This is
much more important. In every browser but IE, the style attribute doesn't render at all thus everything's positioned wrong. This REALLY sucks. It messes up my entire plan. Is this a case of VS.NET doing "smart rendering" for a specific browser and wrecking
my code?
All-Star
191535 Points
20936 Posts
ASPInsiders
Moderator
MVP
Re: Setting Top and Left In Style: 2 Problems
Sep 03, 2004 07:52 AM|XIII|LINK
Working with Azure, chatbots, ASP.NET MVC, Web API, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Member
10 Points
580 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 03:46 AM|BoulderBum|LINK
Member
10 Points
580 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 04:05 AM|BoulderBum|LINK
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 04:08 AM|SomeNewKid|LINK
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 04:55 AM|SomeNewKid|LINK
Member
10 Points
580 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 04:53 PM|BoulderBum|LINK
Member
10 Points
580 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 04:55 PM|BoulderBum|LINK
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 06, 2004 09:04 PM|SomeNewKid|LINK
Member
10 Points
580 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 07, 2004 12:51 AM|BoulderBum|LINK
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 07, 2004 05:34 AM|SomeNewKid|LINK
CreateWebPartManager('HiddenCopyLayer'); document.zoneObject = null; zoneObject = __wpm.AddZone('left', 'left', true, true, 'Blue'); zoneObject.AddWebPart('WebPart1', 'WebPart1Title', true); zoneObject.AddWebPart('WebPart2', 'WebPart2Title', true); zoneObject.AddWebPart('WebPart4', 'WebPart4Title', true);While this may work in IE, it may easily fail in newer, stricter browsers. Just as importantly, some of the WebParts may be placed on the page after the server <form>, so such initialization script would fail in any browser. Of course, this can be remedied by using either RegisterStartupScript or RegisterClientScriptBlock to inject code such as the following:function MyInit() { CreateWebPartManager('HiddenCopyLayer'); document.zoneObject = null; zoneObject = __wpm.AddZone('left', 'left', true, true, 'Blue'); zoneObject.AddWebPart('WebPart1', 'WebPart1Title', true); zoneObject.AddWebPart('WebPart2', 'WebPart2Title', true); zoneObject.AddWebPart('WebPart4', 'WebPart4Title', true); } window.attachEvent("onload", MyInit);That potentially solves the problem of an incomplete DOM when the initialization script runs. But what if another control developer also injects similar window.attachEvent code? I don't think you can have more than one function attached to a DOM event. Another problem is that not all pages use a server side form tag at all. Yet the standard ASP.NET Page requires such a form tag in order to inject any scripts registered by server controls. So, you'll see why I think that when developing a control system that targets the entire page (in contrast to typical server controls which concern themselves only with their little piece of HTML), it is wise to implement your own Page, too. Give your system the level of control it needs, rather than fighting against the standard Page's limitations. And if you're developing a cross-browser system, it seems pointless throwing it onto a page that is IE-centric in every other respect. A cross-browser server control collection deserves a cross-browser Page. > Page control subclass. What you did sounds pretty interesting. Do you know of any good links for the subject? Well, when I started, the following was my guide: Valid XHTML within .NET However, my own Page quickly developed to include MetaBuilders MasterPages control. You see, that control requires a custom Page, too ... as some controls simply must live on a custom Page ... which is why I think it would be completely permissible for your server control collection to require one, too. I also hate the standard limitation of a single <form> tag ... so my custom Page allows for multiple forms, supporting both post-away and postback actions. I haven't yet added the following to my Page class, but I've bookmarked the following article about a custom Page class: Build Your ASP.NET Pages on a Richer BedrockAll-Star
191535 Points
20936 Posts
ASPInsiders
Moderator
MVP
Re: Setting Top and Left In Style: 2 Problems
Sep 07, 2004 02:12 PM|XIII|LINK
Working with Azure, chatbots, ASP.NET MVC, Web API, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 07, 2004 03:31 PM|SomeNewKid|LINK
Participant
1001 Points
7915 Posts
Re: Setting Top and Left In Style: 2 Problems
Sep 08, 2004 01:33 AM|SomeNewKid|LINK