Changes between Version 10 and Version 11 of CodeBestPractices

Timestamp:

2012-02-22 13:55:58 (12 years ago)

Author:

jeroens

Comment:

--

CodeBestPractices

@@ -6 +6 @@
 
 == Resources and localization ==
-Theoretically, the EwE6 scientific interface can be localized to any language, although we do not envy the poor soul commissioned to perform such a job. In intention all language-specific elements in EwE are provided in either localizable forms or in localizable resource tables. We have tried to consistently implement this but exceptions may exist; please let us know if you find any.
+Theoretically, the EwE6 scientific interface can be localized to any language. In intention all language-specific elements in EwE are provided in either localizable forms or in localizable resource tables. We have tried to consistently implement this but exceptions may exist; please let us know if you find any.
 
 The !ScientificInterfaceShared assembly offers a whack of shared resources, such as strings and images, for plug-ins and the main Scientific Interface to share to reduce the amount of scattered resources that need localizing. In your assembly simply add a statement such as import !ScientificInterfaceShared.My.Resources = !SharedResources, and access all shared resources on the imported !SharedResources thingy.
@@ -16 +16 @@
 
 == Target processor ==
-To date, Microsoft has not updated its Access drivers, the core drivers that EwE6 needs to use its database, to 64-bit. EwE6 and ANY EWE6 PLUG-IN must be compiled at ANY TIME for 32 bit processors. Set all applications to build for x86 processors via: Menu > Build > Configuration Manager > x86 (new if not listed). See [https://sources.ecopath.org:8443/trac/Ecopath/attachment/wiki/ScientficInterfaceKnownCompileErrorsFaq/Configuration%20Manager%20x86.png image].
+The EwE source code now fully utilizes 64-bit capabilies. In order to make sure that Windows finds the correct 32 or 64 bit Access drivers make sure you always compile your EwE6 main project against x86 or x64, never against AnyCPU in Menu > Build > Configuration Manager.
+
+Note that 64-bits EwE will not be able to find 32-bit Access database drivers and vice-versa.
 
 == Nasty experiences ==
- * Always override Dispose(bDisposing) to clean up UI elements, do not use [wiki:OnHandleDestroyed !OnHandleDestroyed] because the .NET framework, which wraps Win32 controls, may call this method during the regular life span of a .NET control to do housekeeping. The call may be followed by ! OnHandleCreated - it's simply not a valid trigger to assume your control is dying. 
- * Note that the Visual Studio designer automagically places a Dispose method in its *.designer.vb files which is blocked from debugging. You may want to manually move this method to your main vb file and strip off ! DebuggerNonUserCode tags that prevent the debugger from stepping through the code.
+ * Always override Dispose(bDisposing) to clean up UI elements, do not use !OnHandleDestroyed because the .NET framework, which wraps Win32 controls, may call this method during the regular life span of a .NET control to do housekeeping. The call may be followed by !OnHandleCreated - it's simply not a valid trigger to assume your control is dying. 
+ * Note that the Visual Studio designer automagically places a Dispose method in its *.designer.vb files which is blocked from debugging. You may want to manually move this method to your main vb file and strip off !DebuggerNonUserCode tags that prevent the debugger from stepping through the code.