Dear TMS team,
I am maintaining a huge application that relies heavily on tDBAdvStringGrid. It depends on some specific behavior of this grid, unfortunately the newer tDBAdvGrid is not a usable replacement for this specific application. I have tried many times to switch over to the newer grid but every time I had to rollback my changes and return to good old tDBAdvStringGrid. The changes required in my code are simply too big to justify, I am using several dozens of instances of this grid.
Unfortunately tDBAdvStringGrid is no longer installed by default since you guys deprecated it. To me, that amounts to a lot of extra work each time an update of TMS components is released. I use 3 different versions of Rad Studio so I have to manually edit 6 packages each time an update is released. That's a lot of time consuming labor. I have skipped several updates just to save the hassle.
Hence my plea: Would you please re-introduce tDBAdvStringGrid in the packages? It is perfectly allright for me if the grid appears under a tab "TMS legacy" or "TMS deprecated" or something like that.
Kind regards,
Arthur
We'd like to learn in the first place what is problematic that you can't port to the new TDBAdvGrid?
Other than this, have you considered adding TDBAdvStirngGrid to a separate package (with of course a dependency to the TMS Component Pack package file)? Then you only need to recompile this separate package instead of modifying the TMS Component Pack package files.
Hi Bruno,
I'd rather avoid going into too much detail there, it's simply that the new dbGrid behaves differently from the old one. I have no doubt that the new grid is fantastic but I have far too much code that depends on the exact behaviour and the exact sequence of events of the "old" one.
I am doing some unusual things with the grid. For example, I need to be able to detach the datasource from the grid, perform a query with different parameters and re-attach it to the grid; the grid should show the new data without re-initializing its column widths, the active cell should remain in the same position without flickering etc. This works totally smoothly with tdbAdvStringGrid but not with the new one. Sure I'd figure out a workaround somehow but it would require many days of work and there would be no guarantee that I wouldn't introduce subtle new bugs. I'd rather avoid that since tdbAdvStringGrid simply works perfectly for me.
In fact tdbAdvStringGrid is the only TMS component that I use in this application, since the application is based on a different VCL widget set (LMD Elpack). That has historical reasons; the app was first released in 2003 and was already unicode-enabled then (using Delphi 7!).
TDbAdvStringGrid is the only TMS component I really can't do without - please don't ditch it...
Kind regards,
Arthur
Is in that case keeping TDBAdvStringGrid in a separate package a feasible solution?
I would vastly prefer it if the grid came installed with the rest of the components so I could just rely on the setup.exe and know that it is compiled and installed correctly (under the current state of things, TMS probably wouldn't notice it if the component won't compile anymore...).
It would be perfectly OK for me if the component appears under a "TMS legacy" tab to discourage new users from using it...
It is probably more than 10 years ago that we replaced TDBAdvStringGrid by TDBAdvGrid. Please understand that we do not want to create any new confusion for other users that this component is available nor a burden on our development to keep testing it.
With the use of a separate package having this control, we think it is a minimal effort to just recompile this package when you have installed a TMS Component Pack update.
Thank you for your understanding.
OK, fair enough. I've just succeeded in creating a designtime package that contains just this tdbAdvStringGrid. But can I count on it that it keeps working?
We do all possible efforts to keep TAdvStringGrid & TDBAdvGrid backwards compatible. Since TDBAdvStringGrid descends from TAdvStringGrid, the expectation is that TDBAdvStringGrid will keep working. But please understand that we can't do active testing on this anymore.
Hi Bruno,
I've created a design time package for tDBAdvStringGrid and it seems to work.
Only, in the latest version of TMS Components (dated 6 december 2018), I find that I can only install my package if I compile and install TMS Components manually in the Delphi IDE.
It does not work if TMS' setup.exe compiles and installs the components automatically. In that case I get an error "package tmsded2011 not found" (in Delphi XE).
The package looks like this (file name is TmsArthurXE.dpk ):
-----------------------------------------------------------------------
package TmsArthurXE;
{$R *.res}
{$ALIGN 8}
{$ASSERTIONS ON}
{$BOOLEVAL OFF}
{$DEBUGINFO ON}
{$EXTENDEDSYNTAX ON}
{$IMPORTEDDATA ON}
{$IOCHECKS ON}
{$LOCALSYMBOLS ON}
{$LONGSTRINGS ON}
{$OPENSTRINGS ON}
{$OPTIMIZATION ON}
{$OVERFLOWCHECKS OFF}
{$RANGECHECKS OFF}
{$REFERENCEINFO ON}
{$SAFEDIVIDE OFF}
{$STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$VARSTRINGCHECKS ON}
{$WRITEABLECONST OFF}
{$MINENUMSIZE 1}
{$IMAGEBASE $400000}
{$DESCRIPTION 'Arthurs TMS tdbAdvStringGrid design time support'}
{$DESIGNONLY}
{$IMPLICITBUILD ON}
requires
tmsexd2011,
tmsded2011;
contains
dbgreg,
dbgregde;
end.
--------------------------------------------------------------------------------------
It is really too bad that I have to jump through so many hoops and hurdles just to be able to use this particular component.
It is normal that when a package gets updated (tmsde2011.dcp) that another package depends on (your package tmsarthurxe.dcp) needs to be recompiled. So, whenever you update TMS Component Pack, just open & recompile your package tmsarthurxe.dproj
Hi Bruno,
Of course I re-compiled my package, that's not the problem.
I just can't install it into the IDE. Installing it into the IDE is only possible if I previously compiled/installed TMS components manually. It fails if the setup program installed the components automatically.
Please locate tmsded2011.dcp and make sure the folder where this file is located is added to the library path, so the compiler can find it.
Ouch, that creates yet another path dependency in the IDE, I have too many of those.
I think I'll stick with manual compilation of TMS components, that way the *.dpc and *.bpl files will land where Embarcadero intended them to be.