Issue Details (XML | Word | Printable)

Key: LIBOMV-348
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Jim Radford
Reporter: Jim Radford
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
libopenmetaverse

Changing property on form in any example application causes the project files to be corrupted and form controls disappear

Created: 01/Aug/08 06:52 PM   Updated: 18/Mar/09 09:55 AM
Component/s: Project Files
Affects Version/s: None
Fix Version/s: 0.6.0

File Attachments: 1. Text File corrupt-designer-file.patch (12 kB)


Environment: .NET / Windows64, .NET / Windows32
Steps to Reproduce:
checkout trunk from svn
run 'runprebuild.bat' to create solutiion/project files
open groupmanager example, frmGroupManager.cs
change any property on any control
try and compile

Source file is corrupt, must be checked out from svn again



 Description  « Hide
Editing a form property on any example winform based application causes future compiles to fail and form controls to disappear

The following errors occur while trying to compile:
Error 6 Missing partial modifier on declaration of type 'groupmanager.frmGroupManager'; another partial declaration of this type exists D:\dev\libomv-trunk\Programs\examples\groupmanager\frmGroupManager.Designer.cs 25 20 groupmanager

Error 7 Partial declarations of 'groupmanager.frmGroupManager' have conflicting accessibility modifiers D:\dev\libomv-trunk\Programs\examples\groupmanager\frmGroupManager.cs 13 26 groupmanager

This is possibly something to do with the way Prebuild creates the solution files?



 All   Comments   Change History   Subversion Commits   Patches      Sort Order: Ascending order - Click to sort in descending order
Jim Radford added a comment - 01/Aug/08 06:57 PM
As a temporary workaround you will need to edit the form designer source files outside of the visual studio form designer.

John Hurliman added a comment - 08/Aug/08 03:58 PM
Applied a patch in r2076 that should correct this. Please reopen the issue if you are still seeing problems, and thank you for the report!

Jim Radford added a comment - 18/Mar/09 08:01 AM
Repro:

Open and edit any of our example GUI apps
click Save

Expected:
Changes to be saved

Actual:
Form is completely wiped out


Jim Radford added a comment - 18/Mar/09 08:08 AM
the *.Designer.cs file is getting completely wiped out and the new control added is all that remains in the Designer.cs.

Douglas R Miles added a comment - 18/Mar/09 08:49 AM - edited
Currently you can workarround this by:

1) open up the MyForm.Designer,cs

2) cut out all the Class code .. put it into
MyForm.cs

All that will be left is in Myform.Designer.cs

using...
namespace MyPackege{
internal partial class MyForm { // all this was moved to MyForm.cs }
}

3) Merge anything needed like IntializeComponent()s in MyForm.cs

4) Go int o the Desinger .. change some
.. this will screw up the MyFormDesigner.cs again.. but that is ok...

Take out the first 3 chars (the BOM) (the byte order marker)
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.1433
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
using...
namespace MyPackege{
internal class MyForm { // all this was moved to MyForm.cs } }

Add the word "partial" back into the defination
internal partial class MyForm

Save.. go back into the Designer View again.. AND all is well !

Now all WYSIWYG changes you do will change the IntializeComponent() in MyForm.cs for now on

Most of the time for now on thats the most you'll need to do to the MyForm.Designer.cs what you did above..

With the exception of when you add a new component. Lets say a new textBox15.
All the WYSIWYG stuff works to possition and stuff.. however you will need to declare the variable

in the MyForm.cs
private System.Windows.Forms.TextBox textBox15;


Jim Radford added a comment - 18/Mar/09 09:43 AM
It Appears the problem is extraneous fields being added by prebuild to the .csproj file. Specifically:

<EmbeddedResource Include="Dashboard.resx">
<SubType>Designer</SubType>
<!--<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>Dashboard.Designer.cs</LastGenOutput>-->
<DependentUpon>Dashboard.cs</DependentUpon>
</EmbeddedResource>

Commenting the Generator and LastGenOutput in the csproj appears to fix the issue.

I will update our prebuild system to take these into account for EmbeddedResource nodes.

Jim


Jim Radford added a comment - 18/Mar/09 09:52 AM
Fix applied to r2493, please reopen this issue if you encounter any further issues