I still sort of like to use PSP to edit the images, but you made this easy with your import/export feature. Great job!

Thanks, glad you liked it.

Note that for most programs (including PSP) you don't even need to use the import/export menus. You can just CTRL-C and CTRL-V to copy and paste the images between the two programs.


do you think you could make the "Open" box more like the windows explorer type that opens for most programs? The type you included is the kind that always annoys me because it's a bit difficult to navigate. But this is a minor annoyance.

I'm currently struggling with this. Here is the situation:

I prefer to distribute my programs in as simple a format as possible. I want you to be able to just unzip-and-run, and not worry about installs or DLLs or anything like that.

To that end, this program was written in 16-bit VB3. The beauty of VB3 is that it runs fine on all the new Windows platforms, but its runtime DLLs are small and can be included in the same folder as the EXE. For instance, in my distribution, the two runtime files (vbrun300.dll and cmdialog.vbx) are sitting right there in the same folder and it works great. No need to do a complicated, bloated installer that has to version-mash with crap in your System folder.

But the problems is that since it's a 16-bit program, it can only use the 16-bit "open" dialog. That's the box that irritates you. It irritates me, too, since it won't show long file names.

So, the only option is to port it to 32-bit. I've got two ways to go about it:

1) Do it in C. I tried that first and gave up. Dealing with bitmaps and device contexts is a major pain in the ass in C. Yes, I could do it (I've done it before), but if I had, I'd still be debugging the first prototype instead of having already delivered a fully-featured and polished version. VB development is just so much faster and simpler. All the under-the-hood stuff for dealing with the bitmaps and the clipboard is handled for you. For instance, the command to export a file to a BMP was literally one line of code in this program, and it would have been over a hundred lines if I'd done it in C.

2) Port it forward to VB6. In fact, I've already done it and it works great. There's just a problem with VB6...

The problem with VB6 is that it's bloated. The VB6 runtime library alone is over a megabyte. In addition to that, you have to install a bunch of bullsh*t OLE libraries along with it, making the distribution huge. This irritates me to no end, since I don't even use OLE in the software. This is pure arrogance on the part of Microsoft, making us drag this crap along every time we install a program.

And not only that, the OLE stuff (heck, and even the runtime DLL and the common control OCX) are version-control nightmares. I've seen systems actually quit functioning because of mismatched OLE files. I don't want the weight of that problem to be on my shoulders if I can avoid it.

Sure, microsoft provides their own VB6 runtime installer to handle that crap for you, but that doesn't make it any less bloated. And since I'm using the common control OCX, I'll have to distribute that and version-check it anyway (on one of my test systems I got an "OCX out of date" error because although it already had the OCX, it had an older version).

Still, I want to distribute it in a 32-bit-aware version, and I'm investigating ways to do that easily right now.

One option would be to dump the OCX and call the common dialogs directly via the Windows API. Then I could at least distribute just my zipped VB program and have a corresponding link to the VB6 runtime installer. That way, I'd be able to still have a small, ubloated download for everyone, and only the people who don't have the VB6 and OLE runtimes would need the extra install. This is attractive and I will be investigating it more closely.

Another option would be to follow up on an ad I saw in Dr. Dobbs once. They claimed to be able to turn your DLL-needin' VB program into a stand-alone executable that doesn't have any external dependencies. In effect, statically linking your runtime libraries and OCXs to the EXE. I don't know how well this works or how much it costs, but I'll be investigating that first.

___________
Tony Fabris