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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Passing Values to a User Control 1

Status
Not open for further replies.

qwert231

Programmer
Sep 4, 2001
756
US
I have created a user control that takes a SQL string and creates a custom table. It works well with a static SQL string. (It seemed beyond the scope of datagrids, so bear with me.)

The problem is I would like the control to work more dynamically. I would like the SQL string to change depending on the customer's ID number. Here is what I have for the control:
Code:
<USERCONTROL:testTable id=&quot;testTable1&quot; runat=&quot;Server&quot; cnt=&quot;2&quot; strReq=&quot;SELECT * FROM Customers&quot; />

cnt and strReq are public variables (Integer and String) built into the class I am using for my custom control. As you see here, I am passing a SQL string and it does work. However, I want the string to take a variable for the customer ID. I tried something like this:
Code:
<USERCONTROL:testTable id=&quot;testTable1&quot; runat=&quot;Server&quot; cnt=&quot;2&quot; strReq=&quot;SELECT * FROM Customers WHERE ID LIKE '&quot; & idVariable & &quot;'&quot; />
and:
Code:
<USERCONTROL:testTable id=&quot;testTable1&quot; runat=&quot;Server&quot; cnt=&quot;2&quot; strReq=&quot;SELECT * FROM Customers WHERE ID LIKE '<%= idVariable %>'&quot; />

But both of those gave me errors. Any ideas?
 
just pass the customer id into the user control, and build the sql in there. However, you're going to have one more problem, I think. the <%= construct isn't supported in that context, so you're probably going to need to go for a programatically loaded user control, whereby you set the userID in the codebehind via a new property that you'll set up (custID, or something)

then, load the control into a placeholder via its control collection.

<asp:placeholder id=plcControls runat=server />

in your aspx page, and then in the code-behind:

dim uc as myUserControl
uc = loadControl(&quot;userControls/myUserControl.ascx&quot;)
uc.cnt = 2
uc.custID = yourCustID
plcControls.controls.add(uc)

or something of that nature. I tell you... once you get the hang of adding these types of controls programatically, then you can start nesting them, and it's amazing the things you can do in half the time. I HIGHLY recommend getting comfortable with these methods. IMHO, it's one of the most powerful things you can do to promote re-useability and efficiency in coding w/ASP.NET.

anyway. I'll hop off the box, now.

hth :)
paul
penny1.gif
penny1.gif
 
I'm not worthy, I'm not worthy... just finished reading through the Tidbits post you guys have been putting together. I know just enough to know I wanna know what you guys were talking about. I am seeing the values and benefits of it, but not quite the how-to yet. I'm a guy who pulled himself into programming via ASP w/ VBScript using books, faqs, and message boards. I love the stuff, just can't afford formal education on it. Thankfully I am allowed to hack my way through it at work. (Often proving to provide messy code.)

K, enough groveling.
Got that in the code now (not quite working), what do I need to replace 'myUserControl' with in the line: Dim uc as myUserControl? Thinking... do I still need to register the control? Let me try that... Nope, not sure what goes where yet.
Code:
<%@ Register TagPrefix=&quot;UserControl&quot; TagName=&quot;testTable&quot; Src=&quot;colData.ascx&quot; %>

<script runat=&quot;server&quot;>

    Sub Page_Load(Sender As Object, E As EventArgs)
       dim uc as testTable ' What should this be? Where is this to be declared?
       uc = loadControl(&quot;colData.ascx&quot;)
       uc.cnt = 2
       uc.strReq = &quot;SELECT * FROM Customers WHERE ID LIKE '&quot; & Session(&quot;id&quot;) & &quot;'&quot;
       plcControls.controls.add(uc)
    End Sub

</script>

Then I have the placeholder of course. (I figured, I can pass the SQL string if I hardcode the ID like this:
Code:
<USERCONTROL:testTable id=&quot;testTable1&quot; runat=&quot;Server&quot; cnt=&quot;2&quot; strReq=&quot;SELECT * FROM Customers WHERE ID LIKE '000080&quot; />
so I should be able to programatically load it like what I have above.)
 
Duh!!! The class name!!!! Like this:
Code:
Sub Page_Load(Sender As Object, E As EventArgs)
 dim uc as colData
 uc = loadControl(&quot;colData.ascx&quot;)
 uc.cnt = 2
 uc.strReq = &quot;SELECT * FROM Customers WHERE ID LIKE '&quot; & Session(&quot;id&quot;) & &quot;'&quot;
 plcControls.controls.add(uc)
End Sub

Thanks...
qwert231 reaches skyward and plucks a * for link9.
 
:)

Ok, but consider this. Keeping with the idea of a clean interface, would it not be better to abstract the logic of concatenating that string into the userControl itself?

So that you expose only a custID property, and from that, the user control builds the string, hiding that part of the implementation from the user (which is you, in this case)?

I might not have the whole picture, and maybe you need it to be this way, but I like to pass in smaller bits of information and hide all that concat stuff from the interface completely... even if it were to mean exposing yet another property to tell it which table to pluck the info from.

just ideas, thoughts, and random rambling. it's worth right about what you paid for it. ;-)

paul
penny1.gif
penny1.gif
 
I just thought I would make a tool that would take ANY SQL query and give me a 2 column table...

Field1 Field2 Field3 Field1 Field2 Field3
Record1 Record3
Record2 Record4


Since I can't see Datagrid doing that.
 
Greetings, it is never really a good idea to build SQL within your page, rather use stored procedures.

If your ASP page (default.asp) builds SQL EG:

sSQL= &quot;SELECT username FROM tblLoginDetails WHERE id=&quot; + Request(&quot;UserID&quot;)


Then, imagine 3 scenarios:

1. Innocent Correct Value
=========================
1.1. user types in the following url: &quot;default.asp?UserID=101&quot;
1.2. the following correct sql gets run: &quot;SELECT username FROM tblLoginDetails WHERE id=101

2. Innocent Incorrect Value
===========================
2.1. user types in &quot;default.asp?UserID=QAZ&quot;
2.2. the following incorrect sql gets run causing an error: &quot;SELECT username FROM tblLoginDetails WHERE id=qaz

3. Malicious Incorrect Value
============================
3.1. user types in &quot;default.asp?UserID=101 DROP TABLE tblLoginDetails --&quot;
3.2. sql gets run, then no more tblLoginDetails table: &quot;SELECT username FROM tblLoginDetails WHERE id=101 DROP table tblLoginDetails --&quot;


To prevent this, use Stored Procedures and Parameters
 
That's an interesting take.

However, I'd be interested to see what your solution looks like to avoid this situation, and why you think the same thing could not be avoided by using code checks before executing a sql command that was built on the page.

I'll assume that your argument will be that since parameters are typed, then if you try to assign:

101; DROP TABLE tblLoginDetails

to a parameter w/ type INT, the procedure will puke.

If that is the case, then VB & C# are also strongly typed, and the same set of checks and balances can be put into place.

penny1.gif
penny1.gif
 
This is true, the mail was slightly mis-placed. I mean't in the context of ASP.OLD as at present most Microsoft web apps are written in ASP.old.

Hence no types.

If you want to make a decent attempt at fixing a mess a good place is to start with the data layer. It was mean't as a guide for &quot;qwert231&quot;.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top