Thanks ... I call it a bug :-) One of the guys here is doing a work-around.
Regards Paul McKenzie Analyst Programmer SMSS Ltd. ----- Original Message ----- From: "Max Nilson" <[EMAIL PROTECTED]> To: "'NZ Borland Developers Group - Delphi List'" <[EMAIL PROTECTED]> Sent: Friday, February 20, 2004 3:20 PM Subject: RE: [DUG] Child Remote DataModules Threading > 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 _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
