ASP.net C#: Accessing Button control properties on ASPX from a User Control (ascx)

John_Mc

Hi,

I have a User control embedded in an ASPX page. The Page has a button which I need to access from the ASCX code behind so that I can changes it's visible property to false.

Anyone know how to do this? I'm try this.Parent but the button is not listed by intellisense.

Thanks in advance,
John

Eoin

Will this work?

Parent.FindControl("cmdButton");

stevenmu

You should be able to get it with this.Parent.FindControl("controlid"). You'll probably have to cast it to a button as well to access the properties.

If you're using a master page, you'll have to use the "post-master-izing" controlid. Quick way is to run the page, view source and find the control and note it's id. There is a better way but it escapes me at the moment.

Ginger

Or make sure that the button is public in the ascx control

John_Mc

Nice one lads, that did the trick

Kernel32

I'm sure these methods work but this is really really poor design. Where has the basics of decoupling gone these days? Look up dependency injection and inversion of control.

Evil Phil

Create a property on the control and pass in the id for the control you wish to hide. Which I believe is what Kernel32 is suggesting, never heard it called that before though.

Draupnir

I don't see how this is poorly designed, so long as the user is trying to access a control which is located on some Parent Page class or Master page, in which case this makes sense to me.

I would avoid the use of Parent.FindControl though.

My solution would be:

If say the Parent page is of type MyParentPage, I would cast and hide:

(this.Page as MyParentPage).MyControlName.Visible = False;

mewso

Draupnir wrote: »

I don't see how this is poorly designed, so long as the user is trying to access a control which is located on some Parent Page class or Master page, in which case this makes sense to me.

I would avoid the use of Parent.FindControl though.

My solution would be:

If say the Parent page is of type MyParentPage, I would cast and hide:

(this.Page as MyParentPage).MyControlName.Visible = False;

The only change to that is I would have a public function in the code of my page called say HideButtonA or whatever and call that instead of making the whole button public.

Draupnir

A very fair point, I'll agree with that as being the best way to do it.

Kernel32

Draupnir wrote: »

I don't see how this is poorly designed, so long as the user is trying to access a control which is located on some Parent Page class or Master page, in which case this makes sense to me.

I would avoid the use of Parent.FindControl though.

My solution would be:

If say the Parent page is of type MyParentPage, I would cast and hide:

(this.Page as MyParentPage).MyControlName.Visible = False;

Why is it the fundamentals of OO is thrown out the window so quickly? A user control is essentially a class. A page is a class. You want to keep classes decoupled and cohesive. The code above has created a dependency between two classes when it's not needed. This is how spaghetti code starts.

You have two basic options and both involve creating a contract between the two classes. You can have the user control raise events just like any other control can and the page will handle it's own UI. Or you can create an interface that container classes must implement. The container passes the interface to the sibling and the sibling communicates through the interface. The result is similar though, the container class handles it's own UI and the user control simply communicates it's state. The classes no longer have a dependency on each other but instead communicate through a contract.

Draupnir

But is there really any huge need for that kind of complexity when the architecture of the MasterPage system already provides a very simple way to perform trivial tasks such as hiding controls? I don't believe so.

I would agree with you that event driven methods would certainly be a more OO way to do this, but they would be overkill if hiding a button is the outcome.

I'll give you this though, using an interface would completely be the best way to do this and the most maintainable solution.

Kernel32

Draupnir wrote: »

But is there really any huge need for that kind of complexity when the architecture of the MasterPage system already provides a very simple way to perform trivial tasks such as hiding controls? I don't believe so.

I would agree with you that event driven methods would certainly be a more OO way to do this, but they would be overkill if hiding a button is the outcome.

I'll give you this though, using an interface would completely be the best way to do this and the most maintainable solution.

It depends on how you see things. Where you see complexity I see simplicity. I see an implementation that adheres to the basics of software development that we all purport to understand but is sadly lacking in the industry in general. A lot of developers whine that a lot of what they learn in college is not applicable in real world development. For the most part the problem lies with the developer being unable to bridge the gap between their education and how to apply it so it regresses into hacking.

I'm not trying to be some know it all better than everyone else type person. I learned to program from reading a manual many years ago and never even finished my degree and have hacked my fair share of code. I would just love to see the overall quality of what we produce as industry improved just by going back to the basics.

Draupnir

I'm not going to even try to deny that you make very valid points, I personally don't believe that a lot of the "basics" as you call them can be applied realistically within the ASP.Net development framework of front-end/code behind.

Whilst the ideas you suggest are valid and make software design sense, who is to say that accessing the controls of a master page from within child controls (in scenarios were the developer is fully secure in the knowledge of the existence of said master page and controls) is not as valid and does not make as much software design sense since that is the pattern which is offered to us by the framework we are using?

My point is that there are a HUGE number of software design patterns and practices, but nearly no software development situation is ideally suited to any of them and as such, developers create a new practice/pattern/"basic" to address their problem. I have no desire to attempt complexity for design sake when an equally secure, equally reliable solution is available to me.

Kernel32

Draupnir wrote: »

I'm not going to even try to deny that you make very valid points, I personally don't believe that a lot of the "basics" as you call them can be applied realistically within the ASP.Net development framework of front-end/code behind.

Having worked with asp.net since beta 1 of the 1.0 framework I 100% disagree with that

Draupnir wrote: »

Whilst the ideas you suggest are valid and make software design sense, who is to say that accessing the controls of a master page from within child controls (in scenarios were the developer is fully secure in the knowledge of the existence of said master page and controls) is not as valid and does not make as much software design sense since that is the pattern which is offered to us by the framework we are using?

My point is that there are a HUGE number of software design patterns and practices, but nearly no software development situation is ideally suited to any of them and as such, developers create a new practice/pattern/"basic" to address their problem. I have no desire to attempt complexity for design sake when an equally secure, equally reliable solution is available to me.

The framework doesn't offer a pattern it is a framework and you need to apply pattern. In the same way a car is a framework for transportation, which can get you to work or mow someone down if you so choose, it can perform either function very adequately.

This is where your mindset is. Anti-pattern

Draupnir

My mindset may be anti-pattern to you, but wouldn't you agree with the fundamental software design principle that every anti-pattern is in itself, a pattern?

As I have said all along, your points are valid, but I am always weary of developers or commentators who are so intent on following so called "best practices" that they avoid anything which deviates from what their books, tutorials or god forbid lecturers told them. I am not saying that is what you are doing here either by the way.

I too have worked with ASP.Net since version 1, and have led the design of several significant highly populated .NET web applications and I don't see how you can 100% disagree on my point, I also can't see how you can say that the framework doesn't offer patterns since it is a framework.

Surely, the framework of front end -> code behind is in itself a pattern? I believe that ASP.Net contains its own patterns/best practices/design strategies which supplement the more traditional patterns which you are suggesting. Forget not that the patterns you are recommending were imagined in the 70's, if not the 60's and as technologies move on, we should try to allow patterns to do so too.

Finally, I think it important I make it clear that I do not recommend that a developer calls every piece of hacked code a pattern for the sake of making it allowable, but I do believe that in the case of the .Net framework there are a lot of techniques which can be used that would be frowned upon by the software design purist of old. It's a matter of knowing how and when to use them and also when not to use them.

Evil Phil

I will say that Kernel32 is making a lot of sense to me. Myself I'd use delegates and raise all the events in the the containing page, but that's just me. I do find that use of findcontrol inefficent (isn't it recursive?). I've worked with people who have taken the shorter route to avoid "overly complex" OOP techniques and it has always come back to bite the project in the ass. I've also found that the more familiar you become with such techniques the simpler they seem.

Kernel32

Draupnir wrote: »

My mindset may be anti-pattern to you, but wouldn't you agree with the fundamental software design principle that every anti-pattern is in itself, a pattern?

Thats like equating good behaviour to bad behaviour because they are both behaviours and with that commonality are equally valid. That's not something I would agree with myself.

Draupnir wrote: »

Forget not that the patterns you are recommending were imagined in the 70's, if not the 60's and as technologies move on, we should try to allow patterns to do so too.

You are confusing engineering principles with material. The principles of how to build a bridge or a building are the same now as they were 500 years ago. The construction material has advanced considerably over time allowing for bigger and better to be built but they all adhere to the same principles.

The patterns you are referring too are the core of software engineering principles and have held true for the most part from when they were conceived by C and Smalltalk programmers with great vision to a C# or Java programmer building web applications. Over time the construction material has changed based on the latest and greatest technology advances. Also over time these principles will be refined and may even make a bigger shift here and there but anyone who ignores them is doing a huge disservice to their clients and/or employers.

kayos

Evil Phil wrote: »

Myself I'd use delegates and raise all the events in the the containing page, but that's just me.

Na its not just you, this would be my approach also. The control can raise the events to the page its on and the page can do what it wants on that event. A control should never have in it code that directly ties it to a given page or controls on a page. The Control should work no matter what page you pop it on.

If the OP has created a user control then to me that states it is most likely going to be reused else where. Even if this is not the case right now it would be likely. Its not a case of coding something just for todays requirements but you have to allow for some future reuse be it in another page or project.

Draupnir

Well guys, I can see you are enjoying a little "good design" love in here and I have to say, I agree wholeheartedly with what you are saying. If the guy is writing a user control for reuse across many projects/apps then yes, he should be doing this in the ways you have described.

However, there are circumstances were directly accessing controls in master pages/parent pages etc. makes perfect sense and as such, I wouldn't ever discourage anyone from doing so.

I think the fact is, there are many situations to development and many solutions, our job is to consider the solutions and find the best one. Sometimes that solution follows textbook design patterns, sometimes they do.

@Kernel32: If you don't understand my point about every pattern being an anti-pattern and vice versa, then I suggest you read more on the subject as virtually all of the leading commentators profess this theory in their writing.

JimmyCrackCorn!

I wish design patterns in C# was mandatory reading in college (or an equivalent depending on the day)
Would have saved me lots of haste.

Draupnir

JimmyCrackCorn! wrote: »

I wish design patterns in C# was mandatory reading in college (or an equivalent depending on the day)
Would have saved me lots of haste.

Design patterns would almost certainly have been a module in your degree course? CA in DCU definitely has a module dedicated to it, in 3rd year I think it was.

JimmyCrackCorn!

Draupnir wrote: »

Design patterns would almost certainly have been a module in your degree course? CA in DCU definitely has a module dedicated to it, in 3rd year I think it was.

It wasn't in GMIT and i just wish i found it a few years before i actually did.