Visual Studio breaks Visual Inheritance
I have made a FormBase
, from which I inherit a FomBaseList
and a FormBaseDetail
.
All other forms in the project are derived from FormBaseList
or FormBaseDetail
.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList
I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList
, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList
to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs
with the value found in FormBaseList.Designer.cs
.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
winforms inheritance visual-studio-2015 devexpress devexpress-windows-ui
|
show 4 more comments
I have made a FormBase
, from which I inherit a FomBaseList
and a FormBaseDetail
.
All other forms in the project are derived from FormBaseList
or FormBaseDetail
.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList
I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList
, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList
to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs
with the value found in FormBaseList.Designer.cs
.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
winforms inheritance visual-studio-2015 devexpress devexpress-windows-ui
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16
|
show 4 more comments
I have made a FormBase
, from which I inherit a FomBaseList
and a FormBaseDetail
.
All other forms in the project are derived from FormBaseList
or FormBaseDetail
.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList
I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList
, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList
to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs
with the value found in FormBaseList.Designer.cs
.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
winforms inheritance visual-studio-2015 devexpress devexpress-windows-ui
I have made a FormBase
, from which I inherit a FomBaseList
and a FormBaseDetail
.
All other forms in the project are derived from FormBaseList
or FormBaseDetail
.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList
I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList
, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList
to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs
with the value found in FormBaseList.Designer.cs
.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
winforms inheritance visual-studio-2015 devexpress devexpress-windows-ui
winforms inheritance visual-studio-2015 devexpress devexpress-windows-ui
edited Nov 21 '18 at 10:14
GuidoG
asked Nov 21 '18 at 9:14
GuidoGGuidoG
5,59031945
5,59031945
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16
|
show 4 more comments
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16
|
show 4 more comments
1 Answer
1
active
oldest
votes
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408644%2fvisual-studio-breaks-visual-inheritance%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
add a comment |
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
add a comment |
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
answered Nov 22 '18 at 14:03
GuidoGGuidoG
5,59031945
5,59031945
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408644%2fvisual-studio-breaks-visual-inheritance%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
There is no mechanism built into VS to do this. DevExpress is the kind of control supplier that is likely to include their own code-serializer in their control designer. You ought to ask them.
– Hans Passant
Nov 21 '18 at 10:01
@HansPassant OK I will, at least I know already this now it narrows my search
– GuidoG
Nov 21 '18 at 10:07
Your Another example → I cannot confirm that. When you have a button having an image in the base form, if you change the image of the button in base form and rebuild the project, the button in derived form will show the new image. (Unless you have changed the image of the button in a derived form.)
– Reza Aghaei
Nov 21 '18 at 10:12
First of all, Visual Inheritance on Winforms is not really friendly, if you can avoid it, just avoid it. I know it look sometime to be a great idea on the paper but... My only advice to avoid most of the issue is to ensure that all child form are closed when editing/updating the base form and to build the project after any modification of the base form before opening the child again. Hope it will help you.
– Marco Guignard
Nov 21 '18 at 10:12
@RezaAghaei Well VS has written the property value for the image in all derived Desinger.cs files, so that counts as changing it on the derived forms I guess. The problem is that VS should not have done that in the first place
– GuidoG
Nov 21 '18 at 10:16