I decided to start a new topic for posting my latest version of my grid control, i.e., v9, because the lengthy post here ...http://www.jose.it-berater.org/smfforum/index.php?topic=4176.0
... became too confusing what with so many pages. Within the past week I upgraded the grid control to version 9, as I added a few features to it. So the ActiveX Grid Control is now FHGrid9.dll. It, in both debug and release versions is attached, as well as three test clients/hosts.
In late fall and early winter 2012/2013 I actually started to incorporate the grid into my projects at work, which is what I originally created the grid for. For many years I used the SIGrid Control in my work projects, and this grid was created and designed to replace that one.
I was always impressed by the SIGrid Control, whose underlying architecture was that of a custom control. In other words, an include file was included with the purchase of the grid, and in that were the declares of the exported functions, as well as the UDTs one needed. softwareinnovators.com had compressed the SIGrid.dll with an exe packer, and the dll came to only 49K in size. I always found that to be really impressive, considering that the grid was quite full featured in its capabilities. I’m guessing the un-compacted dll would likely have been in the range of 125K to 150K.
Before using the SIGrid.dll control I had been using the MSFlexGrid.ocx file from Microsoft, and what with everything that had to be installed to make that work, i.e., an ActiveX Control Container, so on and so forth, it added hundreds of kilobytes of dependencies to an application install. In other words, typical of most Microsoft stuff, it was a rather ‘heavy’ OCX.
So when I set out to develop this grid control of my own, I was curious about what size it would end up being. And then there was the issue of creating it in COM ActiveX Control form, as opposed to custom control form. With the control created in COM ActiveX architecture, there would be a serious amount of COM architecture code needing to be housed within the dll, such as all the self-registration code, plus all the code necessary to navigate between the various interfaces that needed to be supported. So what I'm saying is that I didn't think I'd stand a prayer of a chance of being able to beat the SIGrid Control size wise.
Another issue I had at the start was that I wasn't sure which language I wanted to use to code the control. I was thinking of using C or C++ instead of PowerBASIC. I was thinking that if I used C or C++ I could create a 64 bit version. However, in the end I decided to use PowerBASIC. No reason really. I just started using that out of habit I guess, as it goes faster for me than C or C++ what with all the awkwardness of those languages. In terms of the 64 bit issue, that isn't real important to me. Even at work when we upgraded from XP to Windows 7, we stuck with 32 bit Win 7 for backward compatibility reasons.
The release version is coming in at 48 K uncompacted using the PowerBASIC includes. Using the open source UPX executable packer it compacts down to 22016 bytes, which I find rather astounding. So it all turned out good in that regard. Had I used any of the more recent Microsoft C or C++ compilers, I’d likely be looking at sizes double, triple, or even more above what I have.
One of the reasons I believe its possible to make controls so small with PowerBASIC is that if one is using low level COM techniques, i.e., one is building VTables out of UDTs, so on and so forth, these types of structures are inherently simple and small, and it doesn’t translate into a lot of generated machine code. One can see this effect quite easily in C and C++. Just write a short blurb of code to allocate memory for 5 ints using the C runtime’s malloc(), then do the same thing using C++’s new operator, which will cause piles of extra code to be generated.
So attached is the grid code, i.e., FHGrid9.bas, plus three test clients – PBClient1_v9.bas, PBClient2_v9.bas, and PBClient3_v9.bas. While it doesn’t matter which upgrade to the PowerBASIC Windows Compiler Version 10 you use for the clients, i.e., PBWin 10.0, 10.01, 10.02, or 10.03, it does matter which you use to create the FHGrid9.dll. Do not use PBWin 10.03 (the latest version) to create the FHGrid9.dll file. It will cause problems on Windows versions before Windows 7 such as Win 2000/XP. The attached FHGrid9.dll files in Debug and Release versions were compiled with PB Win 10.02. To compile the control you need the source code FHGrid9.bas and the type library file FHGrid9.tlb. All these are attached in seperate attachments.
NOTE 1/4/2014 -- Just added New Zip With Fixes To FHGrid9. The Zip Contains FHGrid9.dll and FHGrid9_Debug.dll. If You Use The Debug Version Rename It To FHGrid9.dll and Temporarily Move Or Rename The Release, i.e., FHGrid9.dll At 22KB. I Believe There Were 46 Downloads Of The Grid, So If Anyone Is Using It They Might Want To Update With This.