Property Sheets

If you find yourself working with MFC property sheets and run into a first-chance exception inside the  ::OnInitDialog method, check that all your dialogs resources have the right windows styles.

 

If you are using dialog resources , check that the dialog resources have the following properties:
 

Border: Thin

Disabled: True

Style: Child

In my case, one of the dialog resource had the 'Border' property set to 'Dialog Frame' and 'Sytle' to 'Pop up'

According to MSDN documentation , for the CPropertySheet::DoModal() method, all the windows styles should be disabled  with the exception of :

DS_3DLOOK	Obsolete. The system automatically applies the three-dimensional look to dialog boxes created by applications.
DS_CONTROL	Creates a dialog box that works well as a child window of another dialog box, much like a page in a property sheet. This style allows the user to tab among the control windows of a child dialog box, use its accelerator keys, and so on.
WS_CHILD 0x40000000L	The window is a child window. A window with this style cannot have a menu bar. This style cannot be used with the WS_POPUP style.
WS_TABSTOP 0x00010000L	The window is a control that can receive the keyboard focus when the user presses the TAB key. Pressing the TAB key changes the keyboard focus to the next control with the WS_TABSTOP style. You can turn this style on and off to change dialog box navigation. To change this style after a window has been created, use the SetWindowLong function. For user-created windows and modeless dialogs to work with tab stops, alter the message loop to call the IsDialogMessage function.

 

And these are optional windows styles, that can be used with the guarantee that they won't cause First-chance exceptions.

DS_SHELLFONT	Indicates that the dialog box should use the system font. The typeface member of the extended dialog box template must be set to MS Shell Dlg. Otherwise, this style has no effect. It is also recommended that you use the DIALOGEX Resource, rather than theDIALOG Resource. For more information, see Dialog Box Fonts. The system selects a font using the font data specified in the pointsize, weight, and italicmembers. The system passes a handle to the font to the dialog box and to each control by sending them the WM_SETFONT message. For descriptions of the format of this font data, see DLGTEMPLATEEX. If neither DS_SHELLFONT nor DS_SETFONT is specified, the extended dialog box template does not include the font data.
DS_LOCALEDIT	Applies to 16-bit applications only. This style directs edit controls in the dialog box to allocate memory from the application's data segment. Otherwise, edit controls allocate storage from a global memory object
WS_CLIPCHILDREN 0x02000000L	Excludes the area occupied by child windows when drawing occurs within the parent window. This style is used when creating the parent window.

 

If you dialog resources are Kosha and you still get a First-change exception is very likely you are experience an exception that is expected (by design) when calling CPropertySheet::DoModal() or CPropertySheet::Create()

You can find out more about this expected exception 'that is safely handled by the operating system' following this link.

On that Microsoft page you will find three methods for resolving the issue.
 

Until next time, see ya.

 

 

Designing to a common interface - Application loggers for SharePoint and ASP .NET

Last week I decided to start working on an application that I am planning to release as an open source initiative. My contribution will not be a framework but rather an application that will help schools to manage their information in a better way.

As I am slowly starting to work on the design of the application I started by tackling one of the Cross-cutting concern: Logging.

It is a good practice to centralized your logging code so if there are changes on the requirements, for the logging of your application, it will be easier to perform these changes.

Consider the case where an application was originally developed with logging to files, on the file system. If there is a change on the logging requirement, say the application needs to write its logs to a Oracle or MSSQL database tables, how easy is to change the code of the application to accommodate this new requirement?

If the logging functionality is scatter all over the different layer of the application then the changes will required a greater effort. On the other hand if the logging functionalities are centralized then the changes are isolated requiring less effort.

When building modules and applications it pays off to develop them having in mind 'Anticipation of Change'.

So I want to have my logging functionality centralized as much as possible and would love to have a common or related logging API for ASP .NET and SharePoint.

After some thinking I came up with the following design

 The logger to be used for SharePoint and ASP .NET implement a common interface. The interface ILogger and the classes that implement this interface , the SharePointLogger and WebLogger, can be built into the same assembly providing a common library that can be shipped for both platforms.

The SharePoint logger inherits from the SharePoint class SPDiagnostServcieBase. Inheriting from the SPDiagnosticsServiceBase allows us to have our own custom diagnostic categories and use the WriteTrace and WriteEvent methods to perform logging. You can read it up more about the SPDiagnosticServiceBase class here

The WebLogger on the other hand contain a logger property that can be an a type of a .NET logger library or framework such as Log4Net.

How the SharePointLogger and WebLogger implements the logging of errors and messages is abstracted from their clients, the classes our component using the logging API. 
In fact we could change the .NET library used by the WebLogger and that shouldn't affect other layers of the application such as the Database layer as long as the interface contract remain the same. The interface contract in this case being the methods Log(String category, String message) and LogError(String category, String message).

This design achieves the objective of centralizing the logging functionality for the application. It also makes it possible to ship the loggers to both platforms ASP .NET and SharePoint.
As an added bonus, we all like bonuses,  this design abstracts the logging logic away from other classes/components.

Many of the concepts that help us to write  re-usable code have its root on sound Software Engineering principles and programming paradigm such as OOP (Object Oriented Programming) help us to implement these principles.

On this note, I would like to recommend you  Fundamentals of Software Engineering (2nd Edition) by Carlo Ghezzi, Mehdi Jazayeri,Dino Mandrioli

This book is timeless and highlight the good principles of developing re-usable and robust software. A good companion book for any serious developer that views writing code as a Craft.

This link to a PDF lecture will give you a highlight of the third chapter of this book where it briefly mention the Software Engineering principles. Other chapters, of the book, dive-in deep into these principles and how to apply them.

We can be agile and write good code. ;-)