| Subject | Re: [IBO] IBO and DevExpress |
|---|---|
| Author | Artur Anjos |
| Post date | 2002-02-22T10:19:55Z |
Lester:
Personnaly, I'm using always TDataset descendants. (If i need to port my appl to other DB, the work it's faster this way). If you are using IB_Grid you are working just for FB-IB/IBO. (That's why it was easy to me to change my appls to IBO the first time). I use TIB_ components a lot, but I put all of them in a place that I can take control and change them when I want to.
Another important parameter in this choice: IBO TDataset descendants are very good are very powerfull.
If IBO could connect to other Databases perhaps I will re-think again about my choice.
That's a question of choices (my company is very small and I need to change things in a fast way, not always the better way). Of course I know that I can use IB_Grid and other components, but I feel more confortable this way. A choice brings us always good things and bad things.
(Developer Express is a company with good components: not very easy to work with - the documentation is very bad, and they do some kind of a mix on the proprieties that will make you think for 6 times before you find what you looking for...- but they work ok, and my users like very much the possibilities and the look & feel.)
Having an application 'eating' twice of the memory need for a buffering dataset is really not important to me, if that dataset is small. (If it is not, I always think that a user don't need to use a very large dataset in a grid online. My question is: why a user will need a grid with 2,000 records? Will he work with that grid? The answer for this question is something like: yes, he will work, but no need to be 'online'. It's a kind of Grid that it's better 'workable' in excel, for example. [Developer Express is quite Good on exporting Data - they have methods like Grid.SaveToXls or Grid.SaveToHTML].
Portability answered to your question?
(Sorry for my english)
Artur
Personnaly, I'm using always TDataset descendants. (If i need to port my appl to other DB, the work it's faster this way). If you are using IB_Grid you are working just for FB-IB/IBO. (That's why it was easy to me to change my appls to IBO the first time). I use TIB_ components a lot, but I put all of them in a place that I can take control and change them when I want to.
Another important parameter in this choice: IBO TDataset descendants are very good are very powerfull.
If IBO could connect to other Databases perhaps I will re-think again about my choice.
That's a question of choices (my company is very small and I need to change things in a fast way, not always the better way). Of course I know that I can use IB_Grid and other components, but I feel more confortable this way. A choice brings us always good things and bad things.
(Developer Express is a company with good components: not very easy to work with - the documentation is very bad, and they do some kind of a mix on the proprieties that will make you think for 6 times before you find what you looking for...- but they work ok, and my users like very much the possibilities and the look & feel.)
Having an application 'eating' twice of the memory need for a buffering dataset is really not important to me, if that dataset is small. (If it is not, I always think that a user don't need to use a very large dataset in a grid online. My question is: why a user will need a grid with 2,000 records? Will he work with that grid? The answer for this question is something like: yes, he will work, but no need to be 'online'. It's a kind of Grid that it's better 'workable' in excel, for example. [Developer Express is quite Good on exporting Data - they have methods like Grid.SaveToXls or Grid.SaveToHTML].
Portability answered to your question?
(Sorry for my english)
Artur
----- Original Message -----
What is missing from IB_Grid that QuantumGrid provides.
I've nearly lost all my rxGrids in favour of IB_Grid, just
it just need extending?
[Non-text portions of this message have been removed]