Cerebrus, I'm certainly going to takeaway quite a bit from your post, as I understand a good bit of what you listed. I'll keep you posted and what I am able to get done, and will ask questions if needed.
A point to bring up on your list though: 1) The user control I'm still learning the inner workings of this control, as it wasn't originally built by me. It has worked flawlessly for me until I decided to get more complex with my code. LOL With that being said, I either don't think there is a bindable feature for the control built into it. I ideally want to modify the code to add quite a bit more stuff to it, as it is a very useful control (or simply learn it better). So as a result, some the events of the control (as of this post) aren't removable in the code behind without crashing the control or modifying the control itself. However, I still can see where I can move the private/public out of the Refresh event of the control. Furthermore, I do want to point out that the hfUserID is used for the person currently logged into the tool, which traps it by the network ID; the user control will not always be populated by the hfUserID (think managerial inputs and delegate inputs for other users). However, I do have other ways to retrieve login ID's without throwing it into a hiddenfield. I'll take your point on that also. I'll keep you posted during the week as to how I come along with your suggestions. Thanks a million! Charles. On Jul 25, 6:40 am, Cerebrus <[email protected]> wrote: > Sorry, I couldn't get to this earlier... Had an extremely hectic > week ! > > I must say that your version of "simplified" is actually far from > simple in my opinion. In order to create a working test page, I had to > remove a lot of stuff (including the custom user control) and had to > create a table structure purely based on deduction. Nevertheless, > after a few hours spent on this, I have a lot of points to elucidate > upon. Note that I have modified the SELECT statements and variable > names as per my convenience. > > 1. Let's start with your UserControl - > _App_Controls_ctlUserNameSelect. I have no idea how it functions or > what properties it exposes but I think the more intuitive way of > handling it would be to use a bindable property of the control instead > of applying checks in the code-behind. I don't really see why you need > to handle Load and Init events of individual controls at all. You also > don't seem to require the hidden field (hfUserID) as an intermediary > to the Username control. For details, read on... > > 2. Regarding the DropDownList, you can simply bind it as follows: > > ASPX: > ---- > <asp:DropDownList ID="ddlRequestType" runat="server" > DataSourceID="dsRequestType" DataTextField="ReqType" > DataValueField="ReqTypeID" SelectedValue='<%# Bind("ReqType") %>' > AppendDataBoundItems="true"> > <asp:ListItem Text="Select" Value="0" /> > </asp:DropDownList> > <asp:SqlDataSource ID="dsRequestType" runat="server" > ConnectionString="<%$ConnectionStrings:MyConn %>" > SelectCommand="SELECT ReqTypeID, ReqType FROM RequestTypes WHERE > ReqCategory = @ReqCategory" OnSelecting="dsRequestType_Selecting"> > <SelectParameters> > <asp:Parameter Name="ReqCategory" Type="String" > DefaultValue="Public" /> > </SelectParameters> > </asp:SqlDataSource> > > Code-behind: > ----------- > protected void dsRequestType_Selecting(object sender, > SqlDataSourceSelectingEventArgs e) > { > string privateOrPublic = GetPrivateOrPublic(); > DbCommand cmd = e.Command; > if ((cmd.Parameters.Count > 0) && (cmd.Parameters.Contains > ("@ReqCategory"))) > { > cmd.Parameters["@ReqCategory"].Value = privateOrPublic; > } > > } > > private string GetPrivateOrPublic() > { > // Return value as a combination of the logic within the > "ctlUserName_Refresh" method and the "hfUserID_Init" method. > // Neither of those methods should be required if this is done > right. > > } > > Note that: > a) I have preferred to handle the SqlDataSource Selecting event and > set the parameter value there instead of retrieving and storing values > in other events such as the Init or Refresh. > b) The GetPrivateOrPublic() method would retrieve the value from the > ServerVariables and AppSettings and store it in a string variable. > This would then be compared with the value in the ctlUserNameSelect > control and "Private"/"Public" would be returned accordingly. > c) I have dispensed with the ddlRequestType_DataBound event and > instead chose to add the Default item "Select" at design time itself. > Setting the "AppendDataBoundItems" property allows me to do this. > d) I bind the "SelectedValue" property of the DDL to my datasource, > which makes sure that the selected value will automatically be set > when selecting data and retrieved when inserting data. > > Using similar logic, I do not require any ControlParameters in the > InsertParameters section of the "dsEntry" SqlDatasource. I can set any > custom parameters in the dsEntry_Inserting event. All other parameter > values should directly result from the property Binding that occurs > during design mode. This pattern precludes the need for having Hidden > fields as an intermediary. > > Therefore, to answer the basic question raised by you, I do think that > not a single hidden field is required in the scenario presented by > you. > > HTH, > -- > Cerebrus.
