I wasn't orginally using a project reference, just a normal binary reference. But that does seem to have fixed it. Thanks.

I've got a rather odd problem which I can't fix, and can't find any information about on the Microsoft sites, so maybe some saged person here can help. In summary, I am referencing a home grown .DLL in my project. The .DLL is relatively simple, it just accesses some legacy BTree files. However with the reference in place, loading up one of the existing forms in the project the form doesn't load - in it's place is a screen saying: An error occurred while loading the document. Fix the error, and then try loading the document again. The error message follows: File or assembly name EPoSAccessLayer.dll, or one of it's dependencies, was not found. I have confirmed that all dependencies are found, and in a brand new project the .DLL does not cause these problems. In the existing project where this reference is causing the form problems, the application will compile and execute without errors. I just can't edit the forms. My current workaround is to remove the reference, and then the forms load up and are OK for editing. So the question is, has anyone else experienced this problem, and if so, do you know the solution for it. Thanks. Martin.

Good grief man! That's beautiful. :-o Thanks < bows down as he backs away slowly >

Network shares aren't the solution. A lot of us grab the latest version onto laptops and work from home using disconnected checkouts (dangerous I know). So, am I not the only one where the file paths are a bit iffy then?

The Problem: I'm running C# and VB.NET projects from sourcesafe, with four developers working on the projects at any given time. The majority of any file references such as .DLLs and .SNK files are done via relative file paths i.e. ..\..\DataAccessLayer.snk. In some cases, this relative approach doesn't work for some PCs that the developers use. Instead they need to use: \VMR\DAL\DataAccessLayer.snk OK, you still with me? Good good. Now here's the final straw. We now have a project where neither of these file paths are allowing the project to compile. Instead it needs an explicit path name including the drive letter: Assembly: AssemblyKeyFile("E:\VMR\DAL\DataAccessLayer.snk") Unfortunately, I cannot impose that every developer keeps their source code on the same drive letter on their machines. The projects must support being installed onto various drive letters. Firstly I cannot understand why a file path will work correctly on one machine and not another - and I have ensured that all the files etc. are in place as they should be. So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter?

Oh yes, this is absolutely an option available to the coders. I wanted to have the best of both worlds. Unfortunately though during development everyone can pick and choose the common components with ease, we're having a bastard time at run-time. Despite having placed the .DLLs in the GAC, the executables cannot find their dependant .DLLs. They only function when the .DLL is sitting in the exe's own directory. I have now lost 50% of my hair. Expecting the other %50 to disappear today.

Thanks for that, that was the answer. Your help is much appreciated.

I'm assuming this is relatively easy and my n00b status is hindering me. I have a set of .DLLs written in C# that want to be able to distribute to other members of development, and instead of them having to browse the hard disk to find my .DLL to place a reference into their app, I want it to come up in the list .NET references. I had assumed that once a .DLL was given a strong name that perhaps the reference list would also show my libraries - but alas no! Is this something relatively easy to do, or are my developers forced to browse reams of folders! Ta.

........and the solution is.....................pass your controls around by reference and not by value....ta da!!

You could try using SendKeys(), which in theory might work, it is placing keys into the keyboard buffer after all, so another app. that has the foucs might well pick them up.

Right, I have a set of Data Access Layer classes that represent their respective SQL Server tables. I have a set of forms where I use the .DataBinding() for each control to bind to properties in my Data Access Layer classes. This was all working great, until I moved the forms into an external .DLL. Now when I call the forms .Show() from the external .DLL I get the message: "An unhandled exception of type 'System.OutOfMemoryException' occurred in system.windows.forms.dll" - Additional information: Error creating window handle. I've traced through the code, and the externals forms will fire up perfectly fine into my apps MDI form, as long as no calls to the data binding take place. Is there any reason why Data Binding won't work across .DLLs????

Problem sorted - it was down to dumb user error :-(

Well, basically I'm getting this error message when calling .Show() on a child form. Before anything is displayed, this exception is thrown. Now it's in the slightly unusual situation, that the MDI window is in a VB.NET application, and all the child forms are supplied in a C# library. So I'm wondering if it's something to do with this?? Any suggestions, hints or tips?

Mmmmmmmmmm, this is interesting. My two development machines are .NET framework 1.0. Your code, and my code do not work on it. Move the same two lots of code onto a machine with .NET 1.1 on it, and hey presto your code works. Mine sadly does not - this however I will put down to duff coding. But I find it had to believe that there's significant enough difference between the two versions for something as fundamental as this to act differently. My range of machines to test on is limited to these three for the moment. But it's definitely food for thought. Would you have been running on 1.1 by any chance?

It has been copied to a new form. Sorry, it's not working here.

It's all happening in the same thread, yes the debugger shows copies are made when added into the collection, 'no' I don't know what's going on, 'yes' I'm throwing my toys out of the pram. All I want to do, is bind textbox's to member variables in a class. And I just want the member variables updated each time the controls .text property is changed - preferably via an event. It's sounds simple enough - but I can't manage it.

Thanks for that. I've compared it against my own code, and yes, they're extremely similar. Have you tried to run yours yet and see if it's making copies instead of references? Because it doesn't allow me to reference a reference of a textbox and let modifications to the textbox ripple through to the original control!! It's all very bizarre, and I'm throwing the toys out of my pram right now.

Yello, I'm suffering from user stupidity at the moment and am hoping someone here can show me the way. I'm attempting to build a class that contains a collection. I have a method in the class called Bind(), which takes a textbox reference and an object reference as it's parameters. These two passed references are then stored into the collection. Simple enough I thought, but the problem appears to be, that I cannot make a reference to a reference. The objects contained within the collection no longer reference the original objects. As as an example, I should be able to pull out one of the textboxes from the collection, change the .text property and see the textbox change on the form. Alas, this is not the case. I have tried just assigning the references to two member variables within the class instead of a collection. Same problem, once the second assigment occurs, I get a copy of the textbox and object and not another reference. Is there something blindingly simple that I'm missing here? Surely in .NET you can reference a reference? Or is there some default behaviour that I don't understand that forces an object to copy itself in this situation. Thanks. Martin

Here's something I've done in the past, you should be able to pull it apart for your own stuff: Private Sub SaveINIFile() Dim strCurrentSection As String Dim ptrRecord As INILayout If strFileName = "" Then Return ptrFileWriter = New System.IO.StreamWriter(strFileName) For Each strCurrentSection In colINISections ptrFileWriter.WriteLine("[" & strCurrentSection & "]") For Each ptrRecord In colINIEntries If ptrRecord.strSection = strCurrentSection Then ptrFileWriter.WriteLine(ptrRecord.strHeader & "=" & ptrRecord.strValue) End If Next Next ptrFileWriter.Close() End Sub

Thanks for your suggestion, but unfortunately the references are still lost, and it would appear when the control and object are passed into the collection, they are passed copies. Sorry for leading you up the garden path by using that .Clone(), I was experimenting in the code - needless to say that didn't work. Anyhows, have implemented exactly what you specified, and the behaviour suggests that you cannot have a reference to a reference!!! In the good old days when I were but a young lad, and sweets were a penny each, and mobile phones were the size of a house, I could just use StrPtr(), but this feature has been ripped out of .NET...........:-(