Paul Mckenzie said: > To me this looks like a major bug (some will call it a feature...) !!!
This issue has come up before, and will probably repeat every time a programmer starts to use multiple instances of objects refering to other global objects. At design time when you point one object at another object, in your case data modules to other data modules, you store globally named object references in the object property, anmd these are streamed out when you save your data modules. These are easily seen as they have a dot in their values, eg 'GlobalModule.tblFred'. This all works perfectly at design time as you only ever have one instance of each designed module existing at a time. And so as you work with your designed modules all of the expected design time stuff functions as you expect. Unfortunately at runtime, when you stream in more than one of these objects refering to other global objects, you get name collisions issues and subquently incorrect object references being generated. As an example let us create two data modules, A and B, where A refers to B.Table. You first create an instance of B, and then an instance of A. The global name space handling code in Classes.pas correctly determines that the reference to "B.Table" in A should be pointed at the appropiate object inside B. Now you create a new instance of B, and because the name is the same as the first B, and they have the same owner, then Delphi must rename the new B to B1. All objects owned by the same owner must have unique names if they are not unnamed. Now when you create a second instance of A (which will get named A1) the global names space code will connect the new reference to "B.Table" to the original B, because the name space matching code works by object name, and your new B was renamed to B1. What you wanted was to have B1 refered to by A1, but that's not something the object streaming code can possibly determine. There are a two possible solutions to this that you can implemen:. 1. As suggested perform manual reference correction when you create A2. This can be made less work by designing some component logic that knows how to plug things together to same you lines of code. This technique can be made "safer" by overriding all of the properties that this happens to in your components and evsuring that they are cleared on loading at runtime. Then you never get any incorrect linkage if you forget to update a link in code. 2. After creating A, rename B (and perhaps A) to have blank names. This removes them from future global name space searches and will allow the next B and A create to work as expected. It is very hard to determine if this behaviour is a bug or a feature, because it all depends on how you write applications. Probably 75% of developers or more never use more than a SDI sort of interface, and many never use data modules at all. So the issues involved in multiple instances of modules areferiung to each other has never has any sort of serious attention paid to it by the Delphi developers. And it would be very hard indeed so see how the this interaction of designtime, runtime, streaming and object naming could be sorted out to handle this sort of thing automatically. Cheers, Max. _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
