Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Accessing data on content page in Master page

Status
Not open for further replies.

wendas

MIS
Apr 20, 2001
92
US
Hi,

I have a few text box entries on the content page. And buttons on the Master page.

When I change an textbox entry on the content page then press a button from the master page, it seems logic goes straight to the master page load, and processes everything, then comes back to the content page to process the textbox_change or textbox_unload or the content page unload.

I need the change from the textbox on content page to be acknowledge by what the button on the master page does.

Can I get an event to process first on the content page? If not can I read the contents of the textbox from the content page while in the master page? (be easier to get content page to set to public field as I will have 5 or 6 different content pages each with different requirements. But I will take what I can get.)
 
you cannot change the page life cycle. this is fundamental to the webform model.

Create member on the master page to set the value.
set the Masterpage attribute on the aspx markup.
within the page textboxchange event handler call the member on the master object
Code:
public void SetTextTo(string text)
{
   SomeLabel.Text = text;
}
Code:
<%@Master page="relative link to master page file" %>
<asp:content>
...
Code:
private void HandlerForTextChangedEvent(object sender, EventArgs e)
{
   Master.SetTextTo(TheTextBox.Text);
   //or you may need to cast
   ((MyMasterPage)Master).SetTextTo(TheTextBox.Text);
}

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Thanks this is helpful, and may help with my 2nd question.

I figured I couldn't change the life cycle, just hoped there was an event I didn't know about.. It shocked me it would go to the master page before doing cleanup on the page it was on.. I even tried setting the textbox postback to true with no change.

I did find a work around with this. Where I could pull the text within the content page by adding this code to the master page.

Code:
 pbl.DateDflt(1) = CType(ContentPlaceHolder1.FindControl("txtDate1"), TextBox).Text

(which I got from looking at examples of masterpages using it.) But then I couldn't uncover any properties of the contentPlaceholder1 that told me WHICH content page was loaded..)

Passing from Content TO Master will help there, (Unless there is a property I have not found..) But not sure if will help on first problem, since I still need code to stop somewhere so content page can pass the code to the master..

It is nice to now know two possibilities of how to work with it. Gives me options for a push-me or pull-you..
 
But then I couldn't uncover any properties of the contentPlaceholder1 that told me WHICH content page was loaded.
nor should it matter. this defeats polymorphism.

think of the master page as a user control the webform/page still controls everything, including which master page to render.

But not sure if will help on first problem, since I still need code to stop somewhere so content page can pass the code to the master..
init, load, textbox.textchanged (with autopostback = true) button click, another control event, etc.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
I figure I can use your logic in load to tell me what content page I have. The program might not care, but if I am responding on the master page to what's passed in the content page, I need to have an idea what fields were on the page.

init & load come b4 anyone can change the textbox, unload doesn't trigger until the master page finishes processing.. I will try the autopostback = true on .textchanged again. but stepping thru code b4 indicated it didn't trigger the event.. Now I need to try it again, you've got me curious (and hopeful again)
 
The program might not care, but if I am responding on the master page to what's passed in the content page, I need to have an idea what fields were on the page.
use the principle "tell don't ask". have the page tell the master page what the value will be. don't have the master page ask the content for text. if you code is dependent on specific concrete implementations, rather than high level abstractions you code becomes unmaintainable.

in this context the exact page is the implementation and the Page object is the high level abstraction.

if you continue down your current path you are working harder, against OOP rather that utilizing the benefits of it.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Thanks, I guess what I am doing I can't see how to more simplify it. I decided to pass a public parameter when calling the specific content page, that way my master page can figure out what it needs from there.

My master page is for binding, displaying to screen or exporting crystal reports to pdf or excel. About 50 reports are useing this Master page.

My content page has either
one date field (about 1/2 of the reports)
a date range (almost the other 1/2 of the reports)
two reports have other very specific field delimiters for filtering like rep number or rate type.

Saves me from building seprate forms for each report, or a different form for each difference of field paramaters needed to pass to Crystal.

Then in master form I needed to pass the date(s) or other entries from the context screen (which I now got with your help) and then for the master form to process I needed to know what parameters to set up and pass to crystal. This now comes down to a 4 part if statement, if singledate -- if daterange -- if other 2 setups -- or ---

Now if I come up with ways to improve the way I am working with Crystal, I have one place to change.

Do I really sound like I'm totally going in the wrong direction?
 
yes, because your master is telling the content what the values are. this would be the same thing if a user control told the page what to do. The webform(page) should be controlling the actions.

your current scenario works, only if there are no changes. what happens when another report is needed with a date and...
you would need to
1. create a new page (required no matter what)
2. change the master page
3. which could effect the other pages because the master is directing the page.

also, master pages were designed to standardize presentation, not functionality. it sounds like you should have 2 webforms and series of web user controls (1 per report) and have the page pass parameters to the web user control(s).

the master page should not know what's happening in the the content section.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Well standardizing presentation is something it does also, all 50 reports should look the same in title, buttons to choose to do PDF, excel, or display to screen (and other various things) and the placement of the CR report.

All that may be different about it is the prompts comeing from the content page.

For any new report, will not need to change any of the stuff in this master or content pages (unless I need a new and different content page for odd prompts, but this will be rare as only 2 of 50 do this now.

This 4 way if statement is all that differentiates it and like said this is rare to change. Everything else on the master page is the exact same thing for all the reports.

Selection of the 50 reports is outside the master & content page on a different web pages all over the site. Once a report is select it sets public properties as to what the report name is, and what content page it will call, then calls that content page. These pages or new pages will be the only thing needed to change to accomedate new reports. (99% of the time) and changing the master page for 1% of the time, I don't think is so bad. It seems to change as easily as any other web page.

Well it may be not good programming technic.. But I just love it, It is working great too. So I guess I am sticking with it.

But that is not to say I don't appreciate all the help you have offered to me.. It just means I'm stubborn and digging in my heels..
 
that's no problem at all.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top