locked
How to obtain event arguments from another procedure in visual basic? RRS feed

  • Question

  • User919364541 posted

    This is a concept question about vidual basic asp coding -- I'm using certain examples, but the question is not about those examples specifically.

    Let's say I have some code in button1_click vb code-behind. 

    In order to perform my desired function, I need access to StatusEventArguments in an event, for example, SqlDatasource_selected.

    Is there a way to access that data from my procedure, or do I have to access it only in the event codebehind and store it in a global or session variable so I can access it in my button1_click procedure?

    For example, from button1_click vb code-behind I want to execute a sqldatasource select and then get access to:

    e.command.parameters("@parmname").value that is contained in sqldatasource1_selected.

    Tuesday, October 27, 2009 12:29 AM

Answers

  • User-952121411 posted

    I was trying to find out if there was a more elegant way to get the command arguments results of an event without having actually insert the event code and pass the results -- answer I think is no.

     

    Correct.  You can walk the object model for the SQLDataSource object to see if there is a way to get data from the control in a parameter (i.e. Me.SQLDs.SelectParameters) and use without calling the event, but I doubt it for what you are looking for.  Here is a link with the SQLDtaaSource Members:

    http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.sqldatasource_members.aspx

    And actually, the way you are trying to avoid is really the way laid out on how to use that type of data control (object data source is similar).  I don't think it is overkill to have the event fire (as designed) to extract the argument values, and then store for use in other functions that need them later.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, October 27, 2009 2:02 PM

All replies

  • User-68639941 posted

    you can store the event argument values in viewstate and access that in your required event

    Tuesday, October 27, 2009 2:48 AM
  • User919364541 posted

    Inside the event procedure, I could store it in Viewstate, Session or a global var.  I wanted to know if there is a way of accomplishing this without storing anything.

    This question was whether there was a way to obtain the result of an event argument another way - without storing it.

    The problem with having an event procedure, in this example, is that it fires at unintended times.  So, I have to control for that with IsPostBack or TRY/Catch.

    In this particular case, I'm executing a SQL/Server stored procedure that has a return value.  The only way to get to the return value is the event argument from procedure Sqldatasource_Selected.  The only reason I need that procedure is to get the return value.

    Conceptually, I was wondering if there was a trick to accessing this from my button1_click procedure without putting the event procedure in code and storing the value somewhere.  Sounds like that is the only way to do it.

    Tuesday, October 27, 2009 10:58 AM
  • User-952121411 posted

    I could store it in Viewstate, Session or a global var
     

    1st, if you had to use any of the (3) above, I would use a session variable.  Viewstate is a bad idea for (2) reasons in your example.

    1. Viewstate is not secure; anything you store in it is in the clients source.  Any type of SQL arguments regardless of what they are should not be readily accessable to the client.
    2. Viewstate makes the page source larger and has several other drawbacks.  There is a time to use Viewstate, and storing values as you need to is better sought for Session varibales IMO.  Take a look to the following in the future for a better understanding of Viewstate:  Understanding ASP.NET View State: http://msdn.microsoft.com/en-us/library/ms972976.aspx

    Ok, now you are probably saying, "I get that, but I am looking for another way to store these values to be accessable between procedure calls.".  Well the wall you are going to hit over and over in ASP.NET and web development in general is that the web is stateless.  Because of this fact, your dilema here is not how to get the stored values accessable between procedure or method calls, but rather how do you persist these values between postbacks.

    If your next statement is, "Well I just need these values to be accesable between method calls on the same postback" then you have it a little easier.  You could wrap up your data in a class object, and just expose that object as a class level variable that is accessable to all page events for that page wihtin a single server call.  Take a look below:

       Private MyPageObject As New CustomObject
    
    
        Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click
    
            'Add values to the class level object
            MyPageObject.Item1 = "Hello"
            MyPageObject.Item2 = "ASP.NET"
    
            'Call TestMethod
            TestMethod()
    
        End Sub
    
        Private Sub TestMethod()
    
            'I can access the value stored in the object within the SAME server call.  This value will be blank
            Dim Value1 As String = MyPageObject.Item1
            Dim Value2 As String = MyPageObject.Item2
    
        End Sub

    Now, if you need these values to persist a Postback, then you will have to add them to a Session variable 1st like below, before accessing them again after Postback:

        Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click
    
            MyPageObject.Item1 = "Hello"
            MyPageObject.Item1 = "ASP.NET"
    
            'Add the object to a session variable
            Session.Add("MyObject", MyPageObject)
    
    
        End Sub


    ...and then access it later like below:

        Private Sub TestMethod()
    
            'Pull the value back out of session
            Dim MyLocalObject As CustomObject = Session("MyObject")
    
            If MyLocalObject IsNot Nothing Then
                MyLocalObject()
    
            End If
    
    
        End Sub


    Your options for unique ways to have data accessable on the web are going to be limited, and really there is nothing too wrong or bad with using some of the concepts of the methodologies above.  Sure, you would probably pass the object as a parameter to the Sub(), but the example was to show how to have the values accessable.

    Hope this helps! Smile

    Tuesday, October 27, 2009 12:40 PM
  • User919364541 posted

    Thanks for detailed response, which I read carefully and understood.

    The custom object is a good idea so I learned something useful there, but the event code is still required and so I stilll have to control for the event firing at undesired times.

    I don't need it to persist postback, so that is not the issue I intended for this thread.

    In your example, testmethod() in my scenario is SqlDataSource_Selected().  It sounds like I am going to need that event code no matter what, because there is no other way to get to its e.command.parameters("myparm").value.

    I was trying to find out if there was a more elegant way to get the command arguments results of an event without having actually insert the event code and pass the results -- answer I think is no.

     

    Tuesday, October 27, 2009 1:07 PM
  • User-952121411 posted

    I was trying to find out if there was a more elegant way to get the command arguments results of an event without having actually insert the event code and pass the results -- answer I think is no.

     

    Correct.  You can walk the object model for the SQLDataSource object to see if there is a way to get data from the control in a parameter (i.e. Me.SQLDs.SelectParameters) and use without calling the event, but I doubt it for what you are looking for.  Here is a link with the SQLDtaaSource Members:

    http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.sqldatasource_members.aspx

    And actually, the way you are trying to avoid is really the way laid out on how to use that type of data control (object data source is similar).  I don't think it is overkill to have the event fire (as designed) to extract the argument values, and then store for use in other functions that need them later.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, October 27, 2009 2:02 PM