I've got a Linq 2 SQL object I'm trying to update. Two of the properties on this object are related to each other, and setting one sets the other.
So if I do:
Foo.Code = BEER;
The Foo.CodeID property will automatically be set to 5 (or whatever.)
The problem is that LinqDataSource sets Foo.Code, then immediately sets Foo.CodeID... which is not bound to anything since we want the users to set just Code. This immediately sets them both back to null.
I know I can use Parameters to default values, but is there any way to just tell LinqDataSource to not even set a property?
EDIT: Worked around issue by creating a hidden field, and assigning the correct value to that in the formview's ItemUpdating event. Would still like to avoid doing the same lookup four times though...
Would it be an option to make the Code property private (select the Code property in the dbml and set the access property in the Properties window) and create a new public property over which you have more control?
I personally have have written a generator that generates the necessary files for me (like sqlmetal), giving me full control over the code. Perhaps this is an option for you as well, if you do not like the generated dbml.
Related
I have this piece of code:
controlDetails = this.form().design(1).addControl(FormControlType::Group, #quickCreateDetails);
controlDetails.dataSource(fbds.id());
controlDetails.dataGroup(#quickCreateDetails);
controlDetails.frameType(10);
controlDetails.autoDataGroup(true);
controlDetails.hideIfEmpty(false);
controlDetails.columns(2);
I want to modify the editability of one certain field on that dataGroup, but I don't know how to do it with code or in the AOT (DS). Seems like Im pretty much limited...
You have next options:
change Form Data Source filed editability
via AOT - https://msdn.microsoft.com/EN-US/library/aa860145.aspx
via code FormDataSource.object: InventTrans_ds.object(fieldNum(InventTrans, Qty)).allowEdit(false)
change child control design property. addControl returns FormBuildGroupControl. Then you have to loop through controlNum(), find correct design control and cast it to one of FormBuildControl nested type with data bounding. There you have allowEdit method.
I tried to set it as a normal page-property, but no luck.
Guess I could use the DynamicProperty class but I really want to avoid this because of the no-cache issue.
Suggestions anyone?
AFAIK the only way to do this is with the DynamicProperty class. If you look at the documentation on the indexer property on the PageData object it says:
Note! Using this indexer will use the Pre and Post handlers for property lookup. I e return values are not guaranteed to belong to the page, but may be dynamic properties, "fetch-data-from"-data etc. To get data guaranteed to belong to this page, use the GetValueand SetValue methods.
Also note that setting values with this indexer will only set values that acually belong to the page, i e you may get a valid value by reading from the indexer, but trying to set a new value for the same index may yield an exception since the value does not exist in the page.
You will need to use the DynamicProperty class:
DynamicProperty myDynProp = DynamicProperty.Load(CurrentPage.PageLink, "PropertyName");
myDynProp.PropertyValue.Value = "new value";
myDynProp.Save();
Alternatively, you could circumvent the Dynamic Property using an idea Joel discusses here
I'm using an ObjectDataSource to perform CRUD operations. For some reason I am getting an "ObjectDataSource 'ObjectDataSource1' has no values to insert. Check that the 'values' dictionary contains values."
Any suggestions?
I understand that this control inherits from the ObjectDataSource Control. According to the documentation http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.objectdatasource.insertmethod.aspx
If the DataObjectTypeName property is set, the method is resolved in a different way. The ObjectDataSource looks for a method with the name that is specified in the InsertMethod property that takes one parameter of the type that is specified in the DataObjectTypeName property.
That's how my ObjectDataSource Control is setup.
<asp: ObjectDataSource ID="ObjectDataSource1" runat="server"
DataObjectTypeName="MyApplication.Entities.Domain.MyObject" ConflictDetection="CompareAllValues"
OldValuesParameterFormatString="original{0}" SelectMethod="GetUserDisplays"
InsertMethod="CreateMyObject" UpdateMethod="UpdateMyObject" DeleteMethod="DeleteDisplay">
</asp:ObjectDataSource>
I set a breakpoint on the InsertMethod, but the application does not even hit it when I try to save my form. I suspect the DataObjectType is not being instantiated properly for some reason.
I'm trying to perform the Insert operation in the EditForm of an ASPxGridview control and the DataObjectType is an EF POCO which has some additional properties (marked virtual) in it to load related entities from the ObjectContext. I think this may be the problem but don't know how to fix it (have looked everywhere!!!).
Any help would be greatly appreciated!
Although I have not been able to determine exactly why the DataObjectType is not being instantiated automatically, I realized that there was an input parameter that needed to be added prior to calling the InsertMethod on the ObjectDataSource. To do this, I needed to add the input parameter (in my scenario anyway) in the Inserting event. Thanks to another post on StackOverflow I was able to figure out that I needed to remove the 'DataObjectTypeName' attribute from the ObjectDataSource for the Inserting event to fire.
I didn't notice a "TypeName" attribute in your ObjectDataSource definition. The DataObjectTypeName according to MSDN is used to identify the class "that the ObjectDataSource control uses for a parameter in an update, insert, or delete data operation, instead of passing individual values from the data-bound control." If the classes are the same (i.e. the CRUD methods class and the data object definition class) then both attributes should be assigned to the same class. If however, your methods are contained in a separate class from your DTO then you would identify each individually.
This helpful post solved the issue for me:
http://dyslexicanaboko.blogspot.com/2012/09/objectdatasource-has-no-values-to.html
I use a lot of repeaters for different elements of our sites, and I've always wondered if there was a way to have the repeater skip an element if an exception occurs instead of having the whole page crash?
In particular, I've inherited a system from another developer that using a similar design, however he didn't include any kind of validation for his business objects, and it a single property is missing, the whole thing goes up in smoke.
Any suggestions?
Thanks in advance!
The simplest suggestion I can offer is the check the validity of the data before it's passed to the repeater. I don't believe there's any way to get the stock repeater to skip a data element on error.
The other approach is to build your own repeater, inheriting from the base Repeater, to add that functionality but I've no sample code to offer. Perhaps someone else may be able to help there.
The way I see it, you have at least three options.
You could create a custom repeater control that inherits System.Web.UI.WebControls.Repeater and override the databinding behaviour to be more try-catchy (probably fail silently on databinding errors). You couldd then easily replace all instances of the standard Repeater with this new one.
You could filter your datasources before databinding to remove items you know are going to cause problems beforehand. This option may be quite laborious and something of an iterative process.
You could try adding default values to the business objects, so that the properties you're binding to return a default instance rather than null (not nice either).
That's my thoughts anyway.
One question - you say "when a property is missing". Do you mean he's using a style of databinding syntax that offers no compile-time checking and is referencing properties that don't exist, or is referecing properties that are null?
Edit
OK, so you're referencing properties that are null. If you have access to the code for the business objects you could modify them so they return a new, non-null instance (this is the third option I gave).
You don't say if you're using .net 3.5, but I'll assume you are. You could add a new property "IsValidForDataBinding" on to each of your business objects. In the getter logic you could check each of the necessary properties and sub-objects to check for validity, non-nullness etc and return a bool. When you come to bind your repeater, write a simple linq statement that filters-out the invalid items (i.e. where IsValidForDataBinding = false). Having said that, I still think that writing a derived repeater control could be your easiest option.
Have you tried using string.isnullorempty("the string") to check for a value before referencing the property?
Here's a reference: MSDN
Ok so the obvious answer is, because the flow of a composite control demands my childcontrols to be created at a certain point in time. I got a problem i think other people must have had as well.
My control is a composite "container/collection" control. It will be fed with an object and based on that objects data it will create a number of childcontrols. So my control will render a header (always) and x-number of, say TextBox controls (based on the object it was fed with).
I'm creating my header in CreateChildControls() obviously, but i can't possibly create my TextBoxes there as well, because i don't know if the object (to base the TextBoxes on) has been fed yet? I thought of exposing a property/method to set/fed the object through, but i'm not sure when it will be called.
So what do i do? I mean i can't possibly create the TextBoxes in CreateChildControls() or can I? I mean - when is CreateChildControls() called - i know i can call EnsureChildControls() (which i already do in a property to set the innerText of the header - since i need the header to be created before setting its innerText obviously).
How about this
var c = new MyContainerControl();
c.Header = "fun";
c.TextBoxObject = myTextBoxes;
That would raise an error (or at best not create any TextBox'es) if i put the building of the TextBoxes in CreateChildControls().
Would it be more sane to instead just store the Header in a member variable and thus not having to call EnsureChildControls() in the exposed method/property setting the Header innerText. I just don't like this aproach much, since it would be complicating things by adding extra logic to store temporarely and later having to figure out when to set it (probably in PreRender).
Also i guess i could make some kind of Databound control, ensuring the data be present at the time of calling .DataBind(). I really don't like this either since last i looked at creating databound controls it got very complicated.
This really should be an easy task to solve - I know I'm missing something somewhere...
what you're describing IS a databound control. And yes, it's somewhat complicated, but it's the proper design paradigm for this type of instance.
That said, had you considered utilizing the repeater control rather than trying to roll out your own composite which behaves in the exact same manner? Rather than passing it a random object, pass it a collection or an iList with the number of text areas you're wanting.