Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 11 total |
An engine component already exists |
Tue, Aug 28 2007 3:34 PM | Permanent Link |
It would be nice if the DBISAM Engine component could just accept that
there are two components in the IDE, perhaps using some expert option or something. I have a project group with more than one project that needs to access a signatured database. Even closing the other form or data module doesn't let it work, which means it is painful switching between them. I understand you can't have two, but if they could work together to maybe even flag that they aren't active right now then that would be better than stopping a form loading at all. Thanks for thinking about it. 8-) /Matthew Jones/ | |
Tue, Aug 28 2007 7:37 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< It would be nice if the DBISAM Engine component could just accept that there are two components in the IDE, perhaps using some expert option or something. I have a project group with more than one project that needs to access a signatured database. Even closing the other form or data module doesn't let it work, which means it is painful switching between them. I understand you can't have two, but if they could work together to maybe even flag that they aren't active right now then that would be better than stopping a form loading at all. >> It's a singleton architecture, so it is basically not possible for there to be more than one instance of the component loaded without there being total confusion as to which settings are being used. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Aug 29 2007 4:24 AM | Permanent Link |
I thought you'd say that, but why not have the component as just a "view"
onto the underlying singleton? Then you could have 53 of the components, and a change in one would be reflected in the others (with possible delays in display - who cares). It is currently a pain (a real one - I have to close the IDE before I can re-open the other form), and the solution isn't hard. Fine, don't fix it for DBISAM, but if ElevateDB has such, please "fix" this for that. /Matthew Jones/ | |
Wed, Aug 29 2007 4:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< I thought you'd say that, but why not have the component as just a "view" onto the underlying singleton? Then you could have 53 of the components, and a change in one would be reflected in the others (with possible delays in display - who cares). >> You say "who cares", but when it comes time to figure out which of the 53 components is actually being used for the settings due to the creation order, etc. it certainly does matter. Allowing more than one instance is a recipe for confusion and more support issues for us. << It is currently a pain (a real one - I have to close the IDE before I can re-open the other form), and the solution isn't hard. Fine, don't fix it for DBISAM, but if ElevateDB has such, please "fix" this for that. >> It's the same issue with ElevateDB, and I'm not "refusing to fix it". On the contrary, there's nothing to fix - it was designed that way. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Aug 29 2007 8:36 PM | Permanent Link |
Phil Read | Hi Matthew,
I don't know if this will help you... You can open your IDE 2 times. i.e run Delphi or C++ Builder two times, then you can access a different project in each instance of your IDE both having a DBISAM Engine component. Not as handy as having 2 projects open in a project group but a possible solution for you. I quite often have 2 copies of C++ Builder running for this sort of thing. Phil. |
Wed, Aug 29 2007 8:38 PM | Permanent Link |
This message was cancelled from within Mozilla.
| |
Thu, Aug 30 2007 2:20 AM | Permanent Link |
This message was cancelled from within Mozilla.
| |
Thu, Aug 30 2007 6:33 AM | Permanent Link |
Tim, you seem to be missing the solution here. Sure you need a singleton.
I have no problem about that. What I'm suggesting is that the singleton be an object created using a normal singleton pattern when needed. The component that we plop on a form then accesses that singleton to set the settings. Of course it would be wrong for anyone to have more than one at runtime, and that too can be checked by registering with the single object and the second one to be created *not in design mode* would complain with an exception. But at design time, it would be real handy to be able to manage multiple projects at the same time. This is restricting the great flexibility of Delphi, and I can't see why it can't be solved while keeping with the singleton requirement. I hope I've explained better how I think this can be done - move the singleton requirement to a global and have the components access that. If more than one tries to access the single one at run time, create an exception. At design time, just let it slide (or display a text property showing "2 components accessing engine"). /Matthew Jones/ | |
Thu, Aug 30 2007 5:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< Tim, you seem to be missing the solution here. Sure you need a singleton. I have no problem about that. What I'm suggesting is that the singleton be an object created using a normal singleton pattern when needed. The component that we plop on a form then accesses that singleton to set the settings. Of course it would be wrong for anyone to have more than one at runtime, and that too can be checked by registering with the single object and the second one to be created *not in design mode* would complain with an exception. But at design time, it would be real handy to be able to manage multiple projects at the same time. This is restricting the great flexibility of Delphi, and I can't see why it can't be solved while keeping with the singleton requirement. I hope I've explained better how I think this can be done - move the singleton requirement to a global and have the components access that. If more than one tries to access the single one at run time, create an exception. At design time, just let it slide (or display a text property showing "2 components accessing engine"). >> You're ignoring the fact that design-time works just like run-time in terms of which settings are used for operating the engine when tables are activated, etc. Allowing more than one engine component would prevent someone from knowing definitively which engine component is being used at design-time to provide the engine settings. Picture opening up a server engine project along with a client engine project at the same time. The best way around this issue is to move any engine settings that you may be using at design-time via the TDBISAMEngine component into run-time code and remove the TDBISAMEngine component from your projects. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Aug 31 2007 5:03 AM | Permanent Link |
> Picture opening up a server
> engine project along with a client engine project at the same time. Hmm, yes, I guess if they are different then that would be awkward! Your workaround - coding it in - does indeed solve it easily, so I'll go with that. Suggestion withdrawn. /Matthew Jones/ |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |