Click here to Skip to main content
Email Password   helpLost your password?

Various screen shots

Introduction

After programming in BASIC, FORTRAN, Assembly, PLI, C, and then C++ for a combined 30+ years, I finally decided to check out the 21st century and write my first meaningful application in .Net. It was going to be a variation of an personal information manager that I had put out as shareware a number of years ago. At first I was enamored with the seemingly endless amount of classes, controls and documentation, and the ease at which one could quickly develop in this new environment. However, it did not take long to realize that there were many deficiencies in the way some of the controls operated, holes in the documentation, as well as outright bugs. As I developed my new application there were many times where I just wish something worked differently.

The first small annoyance was how the progress bar painted the bar in little separate boxes instead of a smooth continuous bar and didn't incorporate a percent complete indicator. Then there was the inability to change colors in the predefined dialogs such as the PrintPreviewDialog and others. Before long I began rolling my own versions of various controls so that I felt I had more control (no pun intended) over how they worked. And, of course, I would have the source code to fix problems and enhance the controls as I had done for years when the MFC source code was freely distributed.

One of the main areas I wanted to coordinate was simply to be able to pick a color scheme for all my controls and somehow everything in the application could easily use that color scheme. Then there were the many simple little things that I wanted that were just not available in the .Net controls, such as the ability to paint a picture in a frame but still get keystroke events (I use that in my LeerColorPicker to allow keystrokes to move the crosshairs around.) And then there was that nasty Interop thing that we needed to use in order to do things that just was not included in the first two iterations of the Framework. I wanted to write much of that stuff once so I wouldn't have to think about it again.

So what are LeerTools?

Simply put, they are a collection of controls, dialogs, methods and some Interop wrappers that worked the way I felt I needed to write the quality of application I hoped to create. And having been a user of some open source code in my career, I decided to give back to the development community and release this suite of tools. Although many of the controls are basically replacements for some things that are available in .Net, either using or just reviewing the code can prove to be useful in several ways:

  1. Some of the controls offer features that are not available in the .Net equivalents.
  2. Some of the controls just don't exist in .Net Framework.
  3. Having the source code makes it easier to customize the controls to your liking.
  4. The concept of the LeerSkin to have a consistent color scheme can certainly be broadened to provide a total look and feel across the controls.
  5. Buried throughout may be interesting examples of how to do certain things and/or workaround known problems.
  6. The collection of additional Methods may save some time in reinventing the wheel.

Note that most of the LeerTools controls do not inherit from the .Net counterparts. For the most part they inherit from very basic classes such as Control, UserControl and NativeWindow.

What is included in LeerTools?

Controls:

Dialogs:

Other goodies:

Using the code

The best way to get started is to unzip the application, compile the solution (please use .Net Framework 1.1 as there are a few bugs that were fixed in 1.1 that I rely on), then add the LeerTools.dll to your VS design tools. If you like, you might create a new section for LeerTools to keep the new controls separate. The sample application is not pretty nor heavily commented, but does demonstrate a good deal of the functionality. The LeerTools source files, however, are extremely heavily commented and I have supplied a reasonably accurate LeerTools.chm documentation file created with NDOC.

Note: LeerTools was written entirely in C# on Windows XP Pro, and tested both in the included sample application as well as in a large scale application that makes moderately heavy use of all the controls. However, there has not been any formal beta testing. There is a lot of code, some of which is depends quite a bit on Windows messaging and it may take a few versions to get any kinks out. In addition, I do not know any reason why they would not be usable in Visual Basic.Net, but I do not use that language and therefore have not tested it. I welcome any feedback (good or bad), requests for changes/enhancements, bug fixes, bug reports or questions. Enjoy.

Known issues

The LeerFilePicker can be a little slow when filling the ListView with the contents of a folder that has a large number of files in it. It may be possible to speed it up if I tapped into the Indexing Service.

History

You must Sign In to use this message board.
 
 
Per page   
 FirstPrevNext
GeneralDesign Issues
Jack Schitt
15:20 3 Jul '06  
While reading your article about why you wrote LeerTools, I noticed something that troubled me a bit:
The first small annoyance was how the progress bar painted the bar in little separate boxes instead of a smooth continuous bar and didn't incorporate a percent complete indicator. Then there was the inability to change colors in the predefined dialogs such as the PrintPreviewDialog and others.

Both of these 'problems' stem from the fact tha windows allows the user to set the system colors and options for display in a program. I seem to recall a method of turning off the segmented progress bar that affects all programs centrally. Similarly, the user may have a preference for their own color scheme over yours. There may even be a very specific setup that the user requires so they can read the screen. Or there may be hardware issues that require the user to use a specific color scheme. My point is, the only time the programmer should choose what color something is is when they are choosing which system color to attach it to. This goes for owner drawn controls as well. (When I draw, for example, a 3d boarder, I use the Draw3DBorder method of the ControlPaint object versus drawing in light grey and dark grey.)

Even though I could not get the sample to run due to a missing dll I have little time to track down and am unwilling to purchase a license for, I did still explore the project a little. One other troubling issue was the use of bitmaps for several font-based standard charachters. The check, option, menu subitem, minimize, maximise, close, dropdown, and various similar symbols are part of the Marlett family of fonts. The hrizontal chevron ( i.e. >> and << ) are part of any other font. For a vertical chevron, draw it at 90 or 270 degrees rotation. Why use a font instead? Combine with size for the button it's going on (retreived from the system setting) and the fontsize the user set (aka onscreen DPI) and you can draw them at any siz and resolution for extreemly sharp graphics. (Usefull for situations with a user who has a super high res monitor with a large font size (yes, it does happen). It prevents your bitmap buttons from showing up either unreasonably small or unreasonably blocky.)

Until at least the missing dependancy is fixed, I won't be able to use your code in my project and will have to find a different control or roll my own. (I needed the File Explorer related controls)
GeneralRe: Design Issues
leerjet
18:05 3 Jul '06  
Although you have chosen to use a somewhat obscene name, I will respond for the benefit of anyone who reads your comments:

1. I am unaware of any global way to change the look and feel of MS progress bars. Even if there were, the need for a progress bar that can be enhanced to the programmer's delight, that already can draw smooth lines and include percentages, even incorporating changing the color of the percentage as the bar crosses, is clear.
2. The point of a toolkit is it gives the programmer the ability to set what color scheme[s] the user can use, whether it is based on system colors or not. All of my controls can use an optional "skin" object which specifies various colors to be used. If YOU choose to set the color items (such as menu foreground, background, select color, etc.) to system colors, your users will get what you say they want.
3. The "missing" .dll you refer to is free for non-commercial use, easy to find as I include the URL right in the article, and you can opt out of using it with a tiny bit of effort modifying the one class I mention.
4. Many of the graphical items you refer to can be set to images of your choice through member properties.
5. I happen to use large fonts on a high res screen and have tested on low-res with small fonts and see little issue with the images to be displayed.
6. The File Explorer controls I wrote were not perfect, and since I wanted to release my own application with almost flawless controls that mimicked Windows versions, I opted to purchase a license for Sky Software's excellent Explorer controls. In any case, my Explorer controls can be used, although they might require some tweaking to make them work the way you want.

However, overriding any of the criticism is the fact that I have donated a whole library of .Net controls, heavily commented source and documentation included. If they don't suit your needs, then by all means look elsewhere.
GeneralRe: Design Issues
Jack Schitt
18:26 3 Jul '06  
I didn't mean to come across as an ass. I do that sometimes though. I actually hadn't looked through the entire code yet and thought that the design of the skinning system prevented the user from editing the colors themselves. My bad.

I think that your code itself is pretty good and if I can fix the issues I have with the code (minor issues, really) then I'll probably end up using it. I have about three different controls (including yours) I'm looking at to figure out which gives the best combo of functionality and ease of use and can be run through FXCop with a miniume of issues.

Sorry for the misunderstanding, again, I didn't mean to attack you.
GeneralRe: Design Issues
leerjet
1:59 4 Jul '06  
Thank you for your considered reply. It takes a lot to apologize in a public forum.

With regards to the tools, I have not maintained the ones here once I went to a 3rd party set of Explorer controls which are not free. My current version of the tools includes a few fixes and a few additional featues. If you run into any issues that appear to be errors with what you have, you can write back and perhaps I can determine if I have already dealt with the problem.

I exclusively use my current version of tools in the robust InfoWonder product that I offer free on my website (http://www.leersoft.com). Although no source will be given away on that product, you will be able to see more examples of how reasonably well the controls perform.
GeneralMessage Removed
desmond5
6:44 3 Oct '04  
Message Removed
GeneralRe: Win32 dependancy
leerjet
4:37 4 Oct '04  
I agree with you that in the ideal world one could write a library using only the high level tools. However, since .Net is largely incomplete in its ability to provide low level access to code necessary to accomplish many of the tasks required by the components in my library, there was really no choice. Until such time as there is a .Net based operating system, as opposed to one that sits on top of our old familiar Win32 base, then there really is no choice.
Generalre Bass library dependency
BillWoodruff
3:02 8 Sep '04  
After fiddling around for fifteen minutes setting startup projects, I finally figured out there is a dependency on something called Bass library. You include a license file relating to this library

I don't think including such 3rd. party libraries which must be paid for if using in future in commercial code is quite the CodeProject model.

imho better you rip out the Bass library and let you work speak for itself.

best, Bill Woodruff

"The greater the social and cultural distances between people, the more magical the light that can spring from their contact." Milan Kundera in Testaments Trahis
GeneralRe: re Bass library dependency
leerjet
9:35 14 Sep '04  
Thank you for your input. I did discuss the dependency with the CodeProject staff before including it. They suggested that I include an easy way to remove its use, which I did by implementing the BASS support via an interface that can be replaced as required by a developer. Perhaps in the next release, should I find any serious errors or get requests for additions/changes, I will include two projects, one with the dependency and one without. Although I only use BASS for a simple sound played when a popup menu pops up, I thought it might be nice to offer the play/record file wrapper for those who are not necessarily writing commercial code, since sound can be a pain with .Net.
GeneralLeerSoft&#65311;&#65311;
lzqwj
23:44 1 Sep '04  
why i don't find 'using LeerSoft.Tools' , System message to me ,don't find this spacename
GeneralLibraries
kuerbis
10:07 31 Aug '04  
Hi

Which classes are in Leer Tools from the Page http://www.un4seen.com or all?

Thomas Bock
GeneralRe: Libraries
leerjet
11:13 31 Aug '04  
The only class in LeerTools that utilizes the BASS library which I obtained from http://www.un4seen.com is the MultiMedia class. The LeerTools MultiMedia class is a wrapper that exposes only the playback of a sound file or a recording of a sound file features from the BASS library. More accurately, my MultiMedia class is a wrapper for the BassLib2.net.dll wrapper (also from un4seen), since BASS.dll is not a .Net library. Furthermore, the only thing in LeerTools that needs the MultiMedia class are the menu classes, since they play a system sound when a popup menu pops up.
If you don't care about the menu sound, you can strip out the code in the MultiMedia class or just implement your own IMultiMedia interface (that is the LeerTools interface that my MultiMedia class implements). As long as you return non-error return codes your implementation doesn't actually have to play any sounds!
GeneralBass.dll?
Furty
3:13 31 Aug '04  
Seems your project has a dependency that has not been included in the distro. After about 15 minutes commenting out code I finally got it to compile, but it may be an idea to include the dependent library or at least a link to it.

The blogless coder
GeneralRe: Bass.dll?
leerjet
4:26 31 Aug '04  
The bass.dll is in two places in the distribution: in the Tools\bin\Release folder as well as the ToolsBoxTest\bin\Release folder. If you are doing a debug version you will have to copy the bass.dll to the appropriate debug folder. Alternatively, you can download the latest bass.dll (which I did before packaging the distribution) at http://www.un4seen.com. Make sure you also move the BassLib2.Net.dll (the .Net wrapper for the bass.dll) and the basswma.dll (handles .wma format) into the folder where you want to run from.


Last Updated 31 Aug 2004 | Advertise | Privacy | Terms of Use | Copyright © CodeProject, 1999-2010