Wolfgang Riedmann Blog

Since I had to repeat often why I choose WPF for .NET programming over WinForms, I have decided to write down my reasons here:

WPF works much better than WinForms on todays high-resolution monitors like FullHD tablets and 4K displays

with WPF it is much easier to build the moden interface designs my customers are asking

WPF has a very powerful binding and is made for modern programming paradigms like MVVM. Therefore it permits a much cleaner design of the program structure

WPF is what Microsoft recommends for new applications

I think, these reasons are worth to discard what I know about the Windows API.

Today unfortunately I have discovered that WinINet calls don’t work in a service.

I need to put a file with FTP somewhere and call than a URL with http to update the data.

Microsoft says that instead of WinINet in a service the WinHTTP functions should be used. Unfortunately, WinHTTP has no support for FTP, so you need to use a 3rd party library in a Win32 service. (I used FCE from Marshallsoft).
And then: the WinHTTP interface is much more complicated to call than WinINET, and after working for a while on the WinHTTP interface (unfortunately it is not implemented in Visual Objects) I decided to use an external call to cURL.

Today unfortunately I discovered that the “VO-way” of developing Windows applications does not work with WPF.

In VO, we used to paint a window in a separate application module, and to not write any code in this generated class. The hand written code was placed instead in a separate module, and in a subclass of the generated window. This separated first written code from generated one, and secondly it was easier to manage.

Unfortunately, WPF does not support such a (IMHO clean) style of programming, as XAML windows cannot be inherited.

I have found a document on MSDN on this subject:

MSDN:make a custom windows inherit from window

and it seems the way of using UserControls is the only remaining possibility to reuse paintend windows.

Since I like VIDE more than Visual Studio, I would continue to use it also on WPF programming with Vulcan.NET.

Unfortunately, VIDE does not support XAML, since it has no XAML editor integrated, and it does not compiles XAML to BAML. At the moment, Chris Pyrgas, the author of VIDE, is searching ways to integrate both a XAML editor and the compiling of XAML to BAML into VIDE.

But fortunately there are methods to accomplish this now. At this moment, I know 3 of them that work, the 4th that would be my favorite one, unfortunatley does not work:

1) don’t use XAML and construct all windows in plain Vulcan code. It gives more flexibility creating the windows, but it seems it willbe more work.
2) create the windows in Visual Studio or Blend, creating C# code. All the other code used for MVVM can be written in Vulcan.NET using VIDE. This was discovered and tested by Frank Maraite who will be able to give also samples.
3) Chris Pyrgas has showed another method: create the windows in Visual Studio as Vulcan.NET projects. Then add the code-behind files as source code files to the VIDE project, and also the VS-compiled resource files as external resources. A sample for this can be requested.
4) this (unfortunately not working) method is called by me “The VO way”, as it uses concepts from Visual Objects. The windows are created in Visual Studio, maybe as based on classes created in VIDE, and compiled to a DLL. Without writing any code, the application itself is written in VIDE, with the VS generated DLL as dependency, and the used windows are inherited from the ones written in Visual Studio. Unfortunately, this method does not work, as the WPF does not support inheriting from a XAML window.

Today, I had the need to intercept the paste of text in a RTF control to remove some formattings (font type and size).

Unfortunately the Richtext control is a special beast, and this is not possible before Windows 8.

On Windows 8, EN_CLIPFORMAT message is sent to the owner window, but unfortunately at this moment there is no way to do this on versions before (I need Windows 7 support). More informations you can find on stackoverflow.com:

http://stackoverflow.com/questions/5618162/detecting-if-paste-event-occurred-inside-a-rich-text-box

My (not perfect) solution consists in a extra context menu on the control that calls my own Paste method.

Since I had added SSL support to the SMTP sending from my application using stunnel, some users don’t opened up the firewall when requested from the operating system (from Windows Vista up).

Therefore I needed to open up the firewall directly from the application.

Since I don’t like to have run the application with elevated rights, I decided to make this change from an external app to spawn from my own application.

It is very simply to add a firewall rule using the netsh command:

netsh advfirewall firewall add rule name=”stunnel” dir=in action=allow program=”c:\tools\stunnel.exe” enable=yes profile=any

(where the stunnel.exe path should be adapted to your own settings).

The problem now was that this command needed to be run with elevated rights, and there is no option to do so.
After a quick search on the internet, I found elevate.exe – a small .NET executable that does what I need: launch a program with elevated rights.

So it was easy: launch elevate.exe (downloadable with sources) and pass as command line the call to netsh.exe.

Today I have lost nearly 4 hours because I had strange crashs in my Vulcan application.

The error returned me to the VO times with the 5333 error – the GPF.

I had this code:

method GetString( cSection as string, cEntry as string, cDefault as string ) as string
local cReturn as string
local oReturn as System.Text.StringBuilder

return cReturn

and sometimes it caused very strange crashes.

I had to correct the code as follows:

method GetString( cSection as string, cEntry as string, cDefault as string ) as string
local cReturn as string
local oReturn as System.Text.StringBuilder

return cReturn

because otherwise the StringBuilder class was initialized only with 64 byte and the API call corrupted the runtime memory.

IMHO such an error should be detected by the stringbuilder class itself.

Today I have lost about two hours to work around a very strange MySQL Connector.NET behaviour.

This code

oMySQLDataReader:IsDbNull( nFieldPos )

gives an exception if the value is a date and has a null value. The exact error was

“unable to convert MySQL date/time value to System.datetime”

I have tried several things, but even

oMySqlDataReader:GetMySQLDateTime( nFieldPos)

fails.
Some messages suggested to add

“Allow Zero Datetime=true;”

to the connection string, but with this one I was unable to retrieve ANY date value.

Only adding

“Convert Zero Datetime=true;”

to the connection string solved the problem.

It was driving me crazy: I was not able to position a form before showing it. It was shown every time the height of my taskbar below the desired vertical position.

The solution was very simple: assign FormStartPosition.Manual to the :StartPosition member of the form:

self:StartPosition := FormStartPosition.Manual
self:Size := Size{ oDesktop:Width, oDesktop:Height }
self:Location := Point{ nX, nY }