Changes between Version 13 and Version 14 of CodeBestPractices


Ignore:
Timestamp:
2012-03-25 20:25:27 (7 years ago)
Author:
jeroens
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CodeBestPractices

    v13 v14  
    33 
    44== Mono compatibility == 
    5 .NET is in theory system-independent, and .NET applications can be deployed under Unix, Linux, MacOS, etc using runtime environments such as [http://www.mono-project.com/Main_Page Mono]. However, not all .NET features work under Mono, most notably the !Microsoft.VisualBasic assembly. This can prove problematic since every Visual Basic project by default receives a reference to this assembly. 
     5.NET is in theory system-independent, and .NET applications can be deployed under Unix, Linux, MacOS, etc using runtime environments such as [http://www.mono-project.com/Main_Page Mono]. However, not all .NET features work under Mono, most notably the !Microsoft.[wiki:VisualBasic] assembly. This can prove problematic since every Visual Basic project by default receives a reference to this assembly. 
    66 
    7 In !EwE we have worked around this problem by redefining key types and constants from the !Microsoft.VisualBasic assembly in [http://webservice.ecopath.org/Ecopath/Help/Index.aspx EwEUtils]. You should not use Chr, Asc, IIF, TriState, MsgBox, UBound, InStr, vbTab, vbCrLF and a whole whack of other old and familiar constructs if you wish your application to run on any other OS than Windows. 
     7In !EwE we have worked around this problem by redefining key types and constants from the Microsoft.!VisualBasic assembly in [http://webservice.ecopath.org/Ecopath/Help/Index.aspx EwEUtils]. You should not use Chr, Asc, IIF, !TriState, !MsgBox, !UBound, !InStr, vbTab, !vbCrLF and a whole whack of other old and familiar constructs if you wish your application to run on any other OS than Windows. 
    88 
    9 To remove reliance on !Microsoft.VisualBasic simply remove the auto-generated reference in the project properties References page. For most constructs .NET offers a solid alternative (for instance !Array.GetUpperBound()), but for other constructs you may have to be creative (vcTab becomes Convert.ToChar(9).ToString() - or do you have a better idea?). 
     9To remove reliance on Microsoft.!VisualBasic simply remove the auto-generated reference in the project properties References page. For most constructs .NET offers a solid alternative (for instance Array.!GetUpperBound()), but for other constructs you may have to be creative (vcTab becomes Convert.!ToChar(9).!ToString() - or do you have a better idea?). 
    1010 
    1111== User Interface design guidelines == 
     
    2727Note that 64-bits EwE will not be able to find 32-bit Access database drivers and vice-versa. 
    2828 
     29---- 
     30 
    2931== Nasty experiences == 
    30  * Always override ''Dispose(bDisposing)'' to clean up sub-classed 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.  
     32 * Always override ''Dispose(bDisposing)'' to clean up sub-classed 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. 
    3133 * 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.