| Subject | Re: About IBX and Firebird |
|---|---|
| Author | mmenaz |
| Post date | 2002-04-12T20:06:46Z |
--- In IBDI@y..., "David Cornelius" <corneliu@o...> wrote:
a) read "getting started guide". It's cheap and very useful
b) study the samples that come with
c) understand that the help for a property of a component very often has to bee searched for the ancestor of that component, where is widely explained (at first I was complaining for the "scarne" help wondering where was the huge help content IBO people was talking about... it's there!)
d) read the source, Luke! In the *.INT (interface) files there is the text that is included in the help.
e) the support list. Plenty of helpful people there
The problem, I think, is not only to go from IBX to IBO, but to go from "paradox" mentality to Client/server. Understanding the Client/server aproach is the more difficoult step. Once you get that, you wonder how you could ever build an true C/S app with components like IBX.
And about RAD and time save: IBO native components have a pretty different aproach with the (native) visual components: lot of visual thing is defined in the query, not in the component. At first it seems bad, but once you get the idea it reveals to be very effective (and you can often override them at component level too). And consider this: my database has a big use of domains. In the connection component I define a lot of attributes for domain that are used by all fields of that domain. Then all the queries of my app automatically inheret them! So I've all date edit and display mask defined, and so for currency ones, uppercase when required, and so on. And if I want to change something.. whell, I have to change it only in one place, and for all the app. In addition, IBO can get fields default value from the server (in a very effective way in the 4.2Gc version), so I can have to define/change only in the database, without having to touch the client app, or worring about they going out of sync.
And this just to name few...
Regards
Marco Menardi
> Hi Kevin,[CUT]
>
> What has helped you most learn IBO? The newsgroups? Just plain experience?You have to:
a) read "getting started guide". It's cheap and very useful
b) study the samples that come with
c) understand that the help for a property of a component very often has to bee searched for the ancestor of that component, where is widely explained (at first I was complaining for the "scarne" help wondering where was the huge help content IBO people was talking about... it's there!)
d) read the source, Luke! In the *.INT (interface) files there is the text that is included in the help.
e) the support list. Plenty of helpful people there
The problem, I think, is not only to go from IBX to IBO, but to go from "paradox" mentality to Client/server. Understanding the Client/server aproach is the more difficoult step. Once you get that, you wonder how you could ever build an true C/S app with components like IBX.
And about RAD and time save: IBO native components have a pretty different aproach with the (native) visual components: lot of visual thing is defined in the query, not in the component. At first it seems bad, but once you get the idea it reveals to be very effective (and you can often override them at component level too). And consider this: my database has a big use of domains. In the connection component I define a lot of attributes for domain that are used by all fields of that domain. Then all the queries of my app automatically inheret them! So I've all date edit and display mask defined, and so for currency ones, uppercase when required, and so on. And if I want to change something.. whell, I have to change it only in one place, and for all the app. In addition, IBO can get fields default value from the server (in a very effective way in the 4.2Gc version), so I can have to define/change only in the database, without having to touch the client app, or worring about they going out of sync.
And this just to name few...
Regards
Marco Menardi