|
I did some more reading and it looks like I need to put a primary key column on my table - and then I guess I will hide it. But even if I add the primary key column how do I resolve the HitTest Row number from the DataGrid into a DataTable row number?
|
|
|
|
|
IIRC, you should be able to get it using DataView[physicalRowIndex]. This gets you a DataRowView. Get the Row property to get the actual DataRow, though if you just want the value of a column in the row, you can get it as you would with a DataRow using the DataRowView.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hey
We have a bigger Game project that is almost finish. It is a Socket based online game.
we have built a Main room there you can chat, creat tables(games) and so on. this section is finish. We have also done a AlfaPet(Scramble) Game to play, but this game is not realy finish yet.
Now to the problem.
We got a dll file(name : Transfer) this dll file contains al the objects we are sending between client and server, thereby it have to be included in bouth the client and Server with the same version.
If we want to change somthing in the dll file(Transfer) then there is no problem to update Server with this dll file becourse we will only have to add it to the server(no own made controls).
But its a bit tricker with the Client.
The client contains alot of own made system controls, so there is not much cod in the client. This controls is using the dll file(Transfer) to send and recive obj.
Every time we make a change in the dll file(Transfer) we have to add it to eatch control and rebuild it and the add it to the client again, otherwice the controls will not be shown in the Client(during in Visual Studio) and somtimes the controls is disiparing. this becource of the version is not matching anymore.
We are tired of doing this way, it must be another way.
Right now we have all the dll files from the own made controls in Client\bin\Debug we have also the Transfer dll file here, the controls have there seartch way to this Client\bin\Debug\Transfer.dll
But if we update it we will have to rebuild the controls, and thats just to time consuming.
Pleas help
Regards
Jimmy
There is som pictures on the application here http://rally.to/Jimmy/
|
|
|
|
|
You don't have to rebuild your application. You can use a publisher policy or add the necessary entries in your assemblyBinding section in your application's .config file. We do it for our massive N-tier application all the time.
Since we also use Internet-based touchless-deployment we only need to change the .config file and upload the new files with the different assembly version. Fusion (binds assemblies in the .NET Framework) downloads the newer assemblies and caches them in the temporary assembly cache. This probably doesn't apply to you, but it doesn't change the fact that you need to recompile your assemblies with dependencies on your Transfer.dll assembly (or whatever it's called) unless you have breaking changes (like removed a method or changed behavior - something to think about when designing your application).
See Redirecting Assembly Versions[^] in the .NET Framework SDK for more information.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hey
Thanks for fast answare
Maby you got the time to explain how to do, becourse im not understan realy what you talking about, but it sounds right
Maby you know where i could find more info about how to do this?
//Jimmy
|
|
|
|
|
Snowjim wrote:
Maby you know where i could find more info about how to do this?
Perhaps the link I sent you in the first reply? 
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hehe Sorry, misst that(was on my way out)
But i have lookt it up, and a remeber that i have lookt at this before, but didnt know how to use it.
I remember that it was somthing about global Assembly witch im not looking for.
I have look in den Client AssemblyInfo.cs i sopose that this is the config file to set? and that this settings will be for al the controls in the project?
if i set oldversion and new version in this file will this solve the problem? will i only have to chansge the version nr next time im updating the transfer.dll?
//Jimmy
|
|
|
|
|
You should re-read it. There's two ways of doing this. One is a publisher policy that gets installed into the Global Assembly Cache (GAC; which I assume you meant by "global Assembly", of which there is no such thing). This is a specially named assembly (among other things) that redirects the assembly binding.
The other is a section in your application's .config file, which is what we used. They both accomplish the same thing. AssemblyInfo.cs is not a config file, either. It simply defines assembly-level attributes (which could go anywhere).
The .config file has the same name as your executable, only with .config appended. So, if your application is MyApp.exe, then your .config file is MyApp.exe.config. The bottom of that article discusses all of this, and even shows you an example of what such entries look like.
So if you upgrade your Transfer.dll from version 1.0.0.0 to version 1.1.0.0, your .config file would look something like this:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Transfer"
publicKeyToken="0123456789abcdef"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="1.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>This would go into the .config file for your client and server. Nothing needs installed into the GAC.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks for all the help
But i cant find any config file at all in our project
When we moved the project from diffrent computers and catalogs we notice that there become som errors in dll files, it was seartching dll files on old places and so on, and there by used older versions of dll files. We coulden find a way to solve this so we desided to pu the project catalog in C:\ and if we moved it to another computer is hade to be in the sam directory there, and this have workt well.
When we ar updating a dll file(User control(own made control)) then we only have to copy the new dll file over the new one.
But the problem with updating a serten dll file that includes in al the usercontrols simes a bit harder.
As i said, i have seartch the project catalog for a file lika *.exe.config, *.config. And i hav also lookt in the catalogs my self, but i cant find a file with that name.
//Jimmy
|
|
|
|
|
You have to create the .config file. How can you have worked with .NET for as long as I know you have (and probably longer) without ever knowing what a .config file is? You can also add a new XML file called App.config to your project and it gets renamed and moved to the target directory when you compile.
When you deploy your application, you make sure the .config file is named the same as your application and in the same directory. For ASP.NET applications, it should be called Web.config. There is plenty of documentation about .config files in the .NET Framework SDK, including the parent section of the link I sent you before.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hehe
yes i wounder the same thing, we have never been tought this thing in school.
and yes you could have learn it my self, and i have tryed, but never manage to understand it. But you have helpt me a great deal, i will try this thing out and see how it goes.
Alot of thanks
//Jimmy
|
|
|
|
|
I never learned any of this (or much of anything I didn't know already about C/C++ and Java) in school either, but yet I know it.
The key is to read. Read that link I sent you in the first reply. It shows you want to put in your .config file as I did. Understanding .config files is also very important. It allows you to custom your application without having to recompile (like storing database connection strings in the appSettings section or something). It also allows you to redirect your assembly binding as we've been talking about.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
No, but beleve me, i work with Programin in C# all the time, and i allways goes out side the lessons bounderys, so i think its wary strange i havent bumped in to this earlier.
And yes i read, but its hard to understand, maby i have to bad ground knowlege.
Anyway
I have made a XML file cald App.config in the project, and i saw that it created a config file named GameClient.exe(not GameClient.exe.config) but it stated that it is a config file.
I have copy the new version of Transfer in to my project, and then open the project, but some of the controls dispare from the form and in the task list it stated ex
Warning: The dependency 'Transfer, Version=1.0.1596.41878, Culture=neutral' in project 'GameClient' cannot be copied to the run directory because it would overwrite the reference 'Transfer, Version=1.0.1602.28586, Culture=neutral'.
The own made control is compiled with the version 1.0.1596.41878 and the config file simes not to work, is there any debug funktion on a XML file? so i know what i have done wrong?
//Jimmy
|
|
|
|
|
Snowjim wrote:
I have made a XML file cald App.config in the project, and i saw that it created a config file named GameClient.exe(not GameClient.exe.config) but it stated that it is a config file
Because you aren't showing all file extensions like a development machine should have. Any registered extensions are hidden. Change this in your folder options for Windows Explorer.
When you work with a multi-project solution, you should set up Project references, not assembly references. This makes sure that the assemblies are in sync: that the right versions are used to compile against and that the right buileds (i.e., Debug, Release, or custom builds) are used.
Again, don't use automatic versioning. In multi-project solutions you'll loose control quickly and it becomes a nightmare to maintain the assembly redirections. You only need to change and redeploy the changed assemblies and the .config file (or have the installer update the existing .config file) but if you use assembly redirection even while testing new versions of your assembly, you have to update the .config file each time. If you redirect to the wrong version you will get exceptions as if the right assembly version wasn't found when JIT'ing your IL.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks for all help!
Im not realy understand how it works, but i will have to look it up.
Anyway, we will try to set Transfer.dll to version 1.0.0.0 and then recompile the controls once and for all. After this we hope that if we make a change in the Transfer.dll we will not have to update al the controls. Yes we will not see what version is the newest, but we can always se on the date when the file is created.
//Jimmy
|
|
|
|
|
What's not to understand? Besides being documented in practically every way you can think of in the .NET Framework SDK, the concept is simple: you have an application and an application configuration file (App.exe and App.exe.config). They go into the same directory. Some settings you can use your application such as the appSettings section via ConfigurationSettings.AppSettings. Some the CLR uses when loading your application, such as assembly binding. Put the XML like I showed you before in that .config file and when the CLR tries to load an older assembly that another assembly references, your .config redirects it to a newer version. So long as the assemblies are compatible, there would be no problems. This is all outlined rather clearly in the SDK. If you don't get it after reading that and my numerous attempts to explain it, then I'll guess you'll have to recompile your client and server applications every time and deploy them in their entirety.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I have understod that.
But this simes only applying to a compiled program(exe file)
I need it to applay even when i start upp the project in Visual Studio.net. I have created a file as you explaned(app.exe.config) and it have got the right name at compilation. But if i close the Project, and copy a new dll file over the old(and ofcours change the version nr in app.exe.config) and then open the project, some controls will be lost due to version errors. I guess that this config file onlye applayes to the compiled file?
And this i dont find any information about, but in general i have problem to understand some of the msdn articles so maby its not that strange.
Anyway, i understand your frustations.
//Jimmy
|
|
|
|
|
No, I said create a file in VS.NET called app.config. VS.NET will automatically rename and copy this file to the target directory with the proper name.
You don't need to do this in VS.NET, though. It's a simple text file - an XML file to be exact - with a .config extension, just like the Web.config file. VS.NET will not benefit from this .config file (at least not until VS.NET 2005) nor will it help you construct it. You need to understand the simple concepts provided in the links I gave you originally. All you're doing is telling the Common Language Runtime (CLR) to bind to a different version of an assembly when a particular version (or version range, which can be used in the oldVersion attribute) is required.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Yes.. i have understand so far, its a regular file with exe.config on the end, and that i can add it by my self or by using Visual Studio. But i diddent know that is only applays to the exe file.
I dont see the point on just adding the new dll file to the exe file, not in our case. there will not be any code in our client that can handle the new funktions in the dll file.
I dont know if we understand eachother.
If i take it again.
We got a client and a server. The Client contains alot of "WindowsControlLibrarys"(own made controls) and this controls includes this Transfer.dll(Collections of classes) that countains all the Classes that we sends between the client and server.
The Transfer.dll file is located in C:\Project\Client\bin\Debug and all the "WindowsControlLibrarys"(own made controls) is including this file at this location(C:\Project\Client\bin\Debug), even the client is using this file itself.
So we hoped that if we compile the "WindowsControlLibrarys" that points at the same Transfer.dll loacated in C:\Project\Client\bin\Debug and includes it to the client, then if we need to update the Transfer.dll we only Close the project, copy the new one over the old one in C:\Project\Client\bin\Debug and then starts up the project again, and by that we dont need to recompile the "WindowsControlLibrarys", but this dident work becourse the "WindowsControlLibrarys" states what version that is included, and tryes to copy this to the C:\Project\Client\bin\Debug directory, witch it cant do becourse there already is a new version.
Then i think of : The "WindowsControlLibrarys" dont need to know of the update in the Transfer.dll, only the client need to know, so if we change the version on the transfer to 1.0.0.0 and recompiles the "WindowsControlLibrarys" with this Transfer.dll then in next update of the Transfer.dll it will not complain becource the new version have the same version(nr 1.0.0.0), and the client will be abled to use the funktions, and maby the own made controls will not aomplain about versions.
This is not a good way to solve this on, becource we will not know what version we are using, insted we will have to look at the date of the file creation.
Proberly this is totaly wrong way to do things, but maby it could work.
I have ready the links, but i cant get it to work in the project, and it simes like it is not supose to do that eather?
//Jimmy
|
|
|
|
|
Thank You.
Sorry For Bad English.
|
|
|
|
|
Not knowing English very well is no excuse for a such a long subject. Next time, please use a brief subject and explain your subject in your post's body.
There are many installers available. The setup and deployment projects in VS.NET are a joke, so forget using them. You might instead take a look at Wise Solutions[^] or InstallShield[^].
Being also an installer author (using the Windows Installer technology), let me tell you that having 59 objects from which the user is to select is not a good idea. Would you like to go through 59 options and decide which to install? I seriously doubt it. I know that I and many others would not.
It's your product: make it easy for the user to install. Combine those 59 options into fewer options with a larger scope or break them down into a tree structure (like Windows Installer features can do).
Think about Microsoft Office. There's probably about that many features in an Professional installation, but they combine them under Word, Excel, Outlook, etc. If users want to be more specific about which options to install under those, they can drill down and select more specific features.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Dear, Sir
Thank You very much for your reply.
My goal is I want to create installer that have tree structure like Microsoft Office Installer.
Is setup and deployment projects in VS.NET can create an installer like Microsoft Office installer?
If it can, how to?
Thank Again.
|
|
|
|
|
No, because the VS.NET installer project does not allow you to specify features or even have a feature dialog. Instead, use Wise for Windows Installer[^] or InstallShield for Windows Installer[^]. I recommend Wise. I've worked with both since Windows Installer 1.0 and each's 1.0 versions and Wise has always been completely extensible (giving you access to all the advanced features of MSI through a table UI) and not nearly as bloated or expensive as InstallShield.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
How can I create a listbox with each item presented by a combobox?
Thanks in advance.
|
|
|
|
|
One idea would be to use owner drawing and in your handler for the DrawItem event (or, if you extend ListBox - which is a better idea for enscapsulation - override OnDrawItem) and use the DrawItemEventArgs.Bounds to position an instance of a ComboBox tied to each item. The trick is to make sure that the ComboBox instances are created and disposed when an object is added or removed from the ListBox. The best way is to extend ListBox.ObjectCollection with your own collection class and override ListBox.CreateItemCollection so that you return an instance of your derivative class.
To make sure that Windows messages are properly dispatched, you may need to add each instance of the ComboBox to the ListBox.Controls collection property. Never tried this, so I'm really not sure. All the owner-drawn ListBoxes I've written and have seen simply draw the items.
See the documentation for the ListBox.DrawMode property in the .NET Framework SDK for more information on owner drawing with a ListBox.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
