Nikolay Pavlov

ListView.  Huh?  Come on, you all know it - the right pane of Windows Explorer.  That is, where contents of folders are displayed.  Whenever you see large icons, or small items listed in columns, or a list of items with details in other columns, it is always one and the same control - ListView.  Kind of a Listbox, but much, much better and powerful.  ListView control came into this world with Windows Explorer back in WIndows 95, and got numerous enhancements eversince.  ListView is very convenient when it comes to display a list of items.  It can even substitute grid controls for read-only data in many cases, as ListView can display multiple columns per data item.  Add support for icons, check boxes, grouping and different layouts, and you have a real beauty.  How to use ListViews is out of the scope of this post.  If you want to learn it - just google for it.  There are tons of tutorials out there.

Great as they are, ListView contols can be very slow with large number of items (like tens of thousands), especially while populating with data.  Furthermore, by default ListView stores all its items internally.  In case you populate the List View from an in-memory collection, you end up with doubled memory usage.  Another thing to be worried about when working with tons of data.

The solution to both the performance and memory-usage issues is to use Virtual ListViews.

(more…)

Further study of the problem on platform target enlightened me that the cause is by using assemblies, compiled with x86 target.  As indicated by Stilgar, these can be any wrappers around 32-bit native code, or COM interops to 32 native COM objects, or any assembly, compiled to target x86.  Examples I know include Managed DirectX assemblies, XNA Framework.  

Similarly, trying to run a x64 assembly on 32-bit Windows will also fail.  Mixing 32-bit and 64-bit code in one application is a “no-no”.

In my case I was referencing a COM object, created in Borland Delphi (obviously native 32-bit code, Delphi still can’t compile 64-bit native).

In short, when you migrate your code to x64, or you want to be sure it will run on 64-bit Windows, please check carefully your dependancies, and pick your platform target accordingly.

Further problems you can have when moving to 64-bit code is the size of datatypes (for example, IntPtr is now 8 bytes instead of 4).  I suggest you read this article at MSDN.

Recently I tried to run a WinForms project, developed for NET Framework 2.0, but in Visual Studio 2008, under Vista Ultimate 64-bit.  To my surprise, it failed with “Win32 error - Bad executable format”.

The project was configured for “Any CPU” platform, which comes by default.  However, the EXE would not start on 64-bit Vista, but would run just fine on any 32 XP or Vista around.  Rebuilding the project under Vista 64 did no good.

Finally, I built it explicitly for x86 platform and it ran without a glitch!

I still have to inestigate why this happened, and what native 32-bit components is the project loading, or is it some misconfiguration.

For the time being, just take the warning - don’t put your life in the hands of “Any CPU” option.  If you want compatibility accross both 32 and 64-bit worlds, just state x86 explicitly.

The first self-organized meeting of the Plovdiv NET User Group will be held on Tuesday, 25th November 2008, starting at 18:30.  The meeting will take place at the Faculty of Mathematics and Informatics of the Plovdiv University.

If you have any questions, just contact me.

Looking forward to meet you there!

It’s been quiet for a while here.  Busy with lots of things both at the office and at home, I found no time to post something worthy.

The news is that I will become in charge for organizing the Plovdiv .NET User Group.  The first meeting is due in November, the date will be set in a week or so.  The first meeting with open with a lecture on C# 3.0 by Stilgar.

I will post the date and time of the meeting immediately when set in stone, so stay tuned!

I was having a nice chat with a friend of mine - a .NET Framework and Windows Forms programmer, and he said:

“It is not possible to access and modify the contents of a window from a thread other than the main one of the application.  And this is how Windows is designed”.

Well, he was wrong.  His mistake comes obviously from the fact that Windows Forms in .NET Framework does not allow you to do so.  If you try to access a control (i.e. a window in Win32 terminology) from another thread, you get a slap on your hands with a nice exception.

In Win32 you definitely can modify from another thread the contents of a window, created in another one.  But believe me, you should not do it.

(more…)

You can tell that a standard push button in Windows XP looks different than a standard push button in WIndows 2000, and such one in Windows Vista.  On top of it, since XP Windows supports visual themes.  The interesting thing is that sometimes one and the same application keeps its Windows 2000 look, but sometimes standard push buttons follow the way of XP, or the Vista, depending on where you run it. 

In this article I explain why.

(more…)

In a recent post I described how a VARIANT variable can be serialized into a binary stream.  That really did the trick back then, and the team lived happily…  Ever after?  Well, no.  A day came when we had to provide a NET-based interface to our application server.

I will not go into details now about the actual design and implementation of the system.  I will only describe an algorithm in NET Framework, which deserializes a binary stream into an appropriate type.

(more…)

Putting Data into the Clipboard

Putting data into the clipboard involves these few steps:

1. Open the clipboard.
2. Empty the clipboard - except for very rare cases, you would better delete what any previous application has put into the clipboard, and replace it with your content.
3. Register a custom clipboard format, if standard ones do not suit you well.
4. Put data into the clipboard.  Repeat steps 3 and 4 for every format you support.
5. Close the clipboard.

Steps 1 and 2 are really straightforward.  You call two API functions - OpenClipboard, and EmptyClipboard.  Registering a custom clipboard format is also a piece of cake.  Simply call RegisterClipboardFormat, pass it a name for it, and store the returned value for later use with SetClipboardData.  If you register a custom format with the same name more than once, the function will return the same value as previous calls - this enables applications to exchange data, as long as they use the same format names.

Putting data into the clipboard is easy if you use NET’s class Clipboard.  Anyway, lets see how it goes the hard way - useful for C++ and Delphi developers out there.

(more…)

Harnessing the full power of Windows clipboard can bring nice user-friendly advantages to your applications.  Face it, users are accustomed to Ctrl + C and Ctrl + V.  Most programmers content themselves with transferring only text data and sometimes images to and from the clipboard, and they do it through the available helper classes and methods of the framework they use - MFC, VCL, NET Framework.  Both Borland VCL and Microsoft NET Framework provide classes, which make it easy to manipulate plain text, images, and sometimes rich text format.  MFC, on the other hand, does little more than providing access to the OLE interface to the clipboard, which is a bit of overkill in my opinion.   Working with standard data is not enough to make a good application.  With little effort the clipboard can be used to integrate you application nicely with other well-written software.

In this article I will explain the basics of the clipboard, demonstrate how it can be used to exchange data with Windows Explorer and Microsoft Word and Excel.  I will deliberately stay away from the dark corners of Windows, where OLE and COM lurk.

(more…)