15 Apr
2009
15 Apr
'09
10:51 a.m.
Sergiu Dumitriu wrote:
fciubotaru (SVN) wrote:
That is a field. While generally speaking public fields are bad practice
they seem to be used by VSTO devs in the add-in class because:
- COM and .NET interoperability is done by using ref parameters. Fields
can be passed as ref, properties cannot.
- They want to keep the addin class files shorter. Properties
significantly increase the length of the file
- Some use public fields and only when a custom getter, setter or
indexer is needed then it's switched to private/protected.
- Properties are slower if not inlined at release.
I'm don't like public fields, but I would like to have the XWikiAddin.cs
file cleaner having only VSTO specific events if possible.
IMO all fields should be encapsulated so I'm thinking at moving them and
the properties in another file but keeping them in the same class.
Then, COM interop will be handled by always boxing/unboxing to local
variables in the methods that call COM, this is what I'm usually doing
anyway.
This would be the fourth file for this class. What do you think about
more files vs less but larger files?
Author: fciubotaru
Date: 2009-04-14 19:28:28 +0200 (Tue, 14 Apr 2009)
New Revision: 18649
Modified:
xoffice/trunk/xword/XWikiLib/XWikiLib.csproj
xoffice/trunk/xword/XWord/AddinActions.cs
xoffice/trunk/xword/XWord/XWikiAddIn.cs
Log:
XOFFICE-74 Navigation Pane does not auto-refresh the tree view when creating a new page
Patch submited by Teofil Achirei, reviewed by Florin Ciubotaru
public string currentPageFullName =
"";
+
/// <summary>
+ /// Specifies if the current page was published on the server.
+ /// It does not specify if the last modifications were saved, but
+ /// if the local document has a coresponding wiki page. It's FALSE
+ /// until first saving to wiki.
+ /// </summary>
Shouldn't properties start with uppercase? I thought that's the convention.
+ public bool currentPagePublished =
false;
+ /// <summary>