Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Designer> When copying a Derived Element the attributes of the Derived Element fields are not copied
 

Pages: 1
Designer
When copying a Derived Element the attributes of the Derived Element fields are not copied
Page:1/1 

  Print all messages in this thread  
Poster Message
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
559 posts
# Posted on: 07-Nov-2018 03:58:24.  
When copying a Derived Element the attributes (e.g System.ComponentModel.DataAnnotations.DisplayAttribute) of the Derived Element fields are not copied, not are custom properties.
  • Right click on a Derived Element - copy
  • Right click on the Containing Model Node - Paste full
The Derived Element attributes are there in the copy but not its fields
V5.4.4 16-Oct-2018
Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8022 posts
# Posted on: 07-Nov-2018 08:32:36.  
Hi Tom,

I reproduced the behavior. When copy/paste derived elements, the custom attributes (code gen info sub tab) are not copied. We will look into this...


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37196 posts
# Posted on: 07-Nov-2018 11:31:30.  
This behavior is by design (for now). The main reasoning is the following:

Quote:
Settings and custom properties aren’t imported for the model elements. The reason is that the project dictates these settings and the elements are imported into an existing project with its own settings. Importing elements with different settings is cumbersome as the user should define settings from the top (project) down to elements (in the case of exceptions), and therefore should do so after importing elements only if it’s necessary for the project. Importing elements with settings makes the user to override these imported settings to the new context (the project), which should be automatic. The settings imported are valid for the source project, not necessarily for the target project. It’s an advanced setting which could be added in the future.


This is the reasoning behind why it's not present in the import system, which is the base of the copy/paste system.

It's a bit of a problem what to do: if we keep the settings/custom properties, and you don't want them in the new context, then you have to manually clean them up which is tedious. If you do want them, then you have to redefine them which is tedious too. the main advantage of the latter is however that (except for custom properties), interfaces and the like are assignable through rules which is the preferred way to do so, at the project level.

Even within the same project it's a problem as it can contain different derived models with their own set of rule based settings.

That said, from your PoV this all likely seems artificial and it should just work, and I agree. The main issue is how to determine when to do what. We already have different 'Paste' options, we could add some more, but it will then be a lot more per element, which also sucks. Dissapointed

At the moment there's little to fix as it works as intended. It's not ideal though, so we need to look at this in a future version, however I don't see a solution that will work for every situation automatically...
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
559 posts
# Posted on: 08-Nov-2018 11:40:49.  
I'm struggling to think of an example of when you wouldn't want a non-inherited attribute, interface or namespace copied over.
It maybe where angels fear to tread but for now I can get by copying a Derived Element by editing the project file in a text editor.


Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37196 posts
# Posted on: 08-Nov-2018 13:43:07.  
Copying an element between projects in different instances, or e.g. importing elements from another project (it's built on the import system after all).

You might need/want other elements defined on your entity/dto or none at all. This then requires you to clean them up after copying. That's a hassle too, so we opted for this.

In the situation where you copy one inside the same model, in the same instance, then there's little chance you'd want to have different elements, fully agreed. Hence we'll look into making the change in a future version to have more flexibility in this area, e.g. through an option which controls the default of this behavior (as there's no real solution which fits all scenarios). (btw copying an entity has the same behavior)
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.