LLBLGenProDataSource2 Bug
Joined: 14-Nov-2006
Joined: 14-Nov-2006
Joined: 14-Nov-2006
Reproduced. Strange issue... 
Will look into it.
When I check the code, I do nothing wrong... 
I return the SAME data, I don't do a refetch. The datasource has no control over what's going to happen with the data, it simply has to return the data requested. It gets a call to fetch data because of the select parameter. Though it checks if this parameter is different from the previous call. It's not, so it decides not to fetch the data again (so it shouldn't reset any controls) and simply hands over the same data as it had in the previous page request.
Frankly I have absolutely NO idea what to do about this. The frustrating part: there's no documentation. So all I can do is decompile SqlDataSource... AGAIN. 
Though.. what I can see there is nothing I don't do too... They also create either a new object or return a cached one. I do that too... I'll what happens when the selectparameter isn't there...
(edit): when the select parameter isn't there, I don't get a call to ExecuteSelect of the datasourcecontrol. When the parameter IS there, I do.
Perhaps I mark something as changed which shouldn't... though at the moment I can't find where that might happen as there's no documentation from MIcrosoft what the order is in which everythign is called, so a gazillion breakpoints are necessary to track down what happens at runtime...
Joined: 14-Nov-2006
Addition: WHen the EnableViewState is false on the dropdownlist, there is a call to ExecuteSelect on the datasource though it's done when the page is setup. So as there's no new data to load, the same data is returned, which is then showing up nicely in the dropdownlist and the proper selected value is indeed marked SELECTED.
When the EnableViewState is set to true on the dropdownlist, there is a call to the executeselect on the datasource though this is done with a different stacktrace: the call originates from a different origin and I assume (nothing is certain here, no docs!) the calling code treats the data returned differently.
Again, I have NO idea why it does work with the sqldatasource and not with my code as all the code that's relevant works the same and the sqldatasource simply also returns an object from ExecuteSelect when it's called, so it's somewhere else but I have no idea where in the 2000 lines I have to look... (and trust me, that happens almost never, only with the datasourcecontrols I have no clue what to do and where to look as the whole framework they operate in is obscure and fragile... )
callstack WITH viewstate:
> SD.LLBLGen.Pro.ORMSupportClasses.DLL!SD.LLBLGen.Pro.ORMSupportClasses.LLBLGenProDataSourceView2.ExecuteSelect( System.Web.UI.DataSourceSelectArguments arguments = {System.Web.UI.DataSourceSelectArguments}) Line 1054 C#
System.Web.dll!System.Web.UI.WebControls.ListControl.OnDataBinding(System.EventArgs e) + 0x5d bytes
System.Web.dll!System.Web.UI.WebControls.ListControl.PerformSelect() + 0x20 bytes
System.Web.dll!System.Web.UI.WebControls.BaseDataBoundControl.DataBind() + 0x47 bytes
System.Web.dll!System.Web.UI.WebControls.BaseDataBoundControl.EnsureDataBound() + 0x53 bytes
System.Web.dll!System.Web.UI.WebControls.ListControl.OnPreRender(System.EventArgs e = {System.EventArgs}) + 0x1b bytes
System.Web.dll!System.Web.UI.Control.PreRenderRecursiveInternal() + 0x4e bytes
System.Web.dll!System.Web.UI.Control.PreRenderRecursiveInternal() + 0xa2 bytes
System.Web.dll!System.Web.UI.Control.PreRenderRecursiveInternal() + 0xa2 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequestMain(bool includeStagesBeforeAsyncPoint = true, bool includeStagesAfterAsyncPoint = true) + 0x551 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest(bool includeStagesBeforeAsyncPoint, bool includeStagesAfterAsyncPoint = true) + 0x4d bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest() + 0x57 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext context) + 0x13 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest(System.Web.HttpContext context) + 0x32 bytes
App_Web_azinjwr2.dll!ASP.default15_aspx.ProcessRequest(System.Web.HttpContext context = {System.Web.HttpContext}) + 0x2f bytes C#
System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep. Execute() + 0x9b bytes
System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step = {System.Web.HttpApplication.CallHandlerExecutionStep}, ref bool completedSynchronously = true) + 0x41 bytes
callstack with viewstate is false:
> SD.LLBLGen.Pro.ORMSupportClasses.DLL!SD.LLBLGen.Pro.ORMSupportClasses.LLBLGenProDataSourceView2.ExecuteSelect( System.Web.UI.DataSourceSelectArguments arguments = {System.Web.UI.DataSourceSelectArguments}) Line 1054 C#
System.Web.dll!System.Web.UI.WebControls.ListControl.OnDataBinding(System.EventArgs e) + 0x5d bytes
System.Web.dll!System.Web.UI.WebControls.ListControl.PerformSelect() + 0x20 bytes
System.Web.dll!System.Web.UI.WebControls.BaseDataBoundControl.DataBind() + 0x47 bytes
System.Web.dll!System.Web.UI.WebControls.BaseDataBoundControl.EnsureDataBound() + 0x53 bytes
System.Web.dll!System.Web.UI.WebControls.DropDownList.LoadPostData(string postDataKey = "OrderDropDownList", System.Collections.Specialized.NameValueCollection postCollection) + 0x1e bytes
System.Web.dll!System.Web.UI.WebControls.DropDownList.System.Web.UI.IPostBackDataHandler.LoadPostData(string postDataKey, System.Collections.Specialized.NameValueCollection postCollection) + 0xc bytes
System.Web.dll!System.Web.UI.Page.ProcessPostData(System.Collections.Specialized.NameValueCollection postData, bool fBeforeLoad = true) + 0x199 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequestMain(bool includeStagesBeforeAsyncPoint = true, bool includeStagesAfterAsyncPoint = true) + 0xec1 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest(bool includeStagesBeforeAsyncPoint, bool includeStagesAfterAsyncPoint = true) + 0x4d bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest() + 0x57 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext context) + 0x13 bytes
System.Web.dll!System.Web.UI.Page.ProcessRequest(System.Web.HttpContext context) + 0x32 bytes
App_Web_hwa0yqx8.dll!ASP.default15_aspx.ProcessRequest(System.Web.HttpContext context = {System.Web.HttpContext}) + 0x2f bytes C#
System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep .Execute() + 0x9b bytes
System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step = {System.Web.HttpApplication.CallHandlerExecutionStep}, ref bool completedSynchronously = true) + 0x41 bytes
System.Web.dll!System.Web.HttpApplication.ResumeSteps(System.Exception error) + 0x163 bytes
One interesting thing is that when viewstate is enabled on the combobox: I get an event that the parameters have changed AFTER the page loaded. (relevant code is identical to sqldatasource control's code) This event raises the changed event of the datasourcecontrol and AFTER that the select call takes place
However... when I have viewstate disabled on the combo box, this event NEVER happens.... Why? I have no idea, though the same steps occur: page load event occurs, parameters are updated but that doesn't raise an event to signal the parameters have been changed. The select call still comes but from a different routine. As the datasourcecontrol by itself sees the select parameters haven't changed, it doesn't do a fetch call again and simply returns the same data.
Now if anyone knows any documentation why this happens, I'm all ears. But at the moment I have 100% no idea.
(edit) what's also silly is that the parametercollection object raises the changed event while the only parameter in it isn't changed at all...
(edit) Ok, the parameter contents gets changed, because the customer combobox value is inserted as the value of the parameter.
I find it strange that the parameter doesn't have a value defined at all, as I do have tracking enabled and it's thus stored (has to be) in the viewstate... So the value set after the page is loaded is then changing it.
It's even more strange that this happens when enableviewstate is enabled while it does work properly when enableviewstate is disabled...
(edit) ok, when the selectparameter is a defaultvalue parameter, the parameter already has the value to set (gets the same value) and therefore doesn't change and nothing happens.
It seems that the original parameter values aren't stored in the viewstate apparently even though everything has viewstate enabled. So the read from the viewstate isn't setting any parameter value, then the value is set from the customer combobox, obviously a change and then the select call is made.
Looking further.
Joined: 14-Nov-2006
Tears of joy!
Ok, a couple of months back I fixed an issue (hence the reason I said earlier to download the latest version as this was fixed some time ago) where a combobox was reset to the initial value (when bound to a datasource control AND with a select parameter) due to a postback from a button. I then discovered after an afternoon of searching that the selectparameters apparently were different so I had to cache the old ones and compare with the current ones, and if there was no difference simply return the old cached data. This solved that particular problem, but it was in fact the SAME issue.
I know simply cache the selectparameter values properly like the datasource controls of ms do (thanks to the one true documentation we have: reflector 
) and it works like a charm! 
Fixed in build 2.0.0.061201 of the runtime libraries. If you need the runtimelibs NOW please let me know otherwise wait a couple of days before we upload a new build to the website.
(I'll now clean up that old fix as it's not needed anymore, so it's not fully finalized yet).
Ok done.
Joined: 14-Nov-2006
Congratulations!