MyObject is already using the ExpandableObjectConverter that's not the problem. It's the MyField property. If I use an ExpandableObjectConverter for this property, the property becomes editable, but as a string not an enum. I think I need to use some kind of EnumConverter and dynamically specify the enum type, but I don't know how.
You wanna make a typeconvertor for the type and apply that. The key methods to override (implement) is SupportValues() and GetSupportedValuesCollection() (the method names are most likely wrong too lazy to look them up). This will automaticaly create an "enum" like convertor, do not implemeted any other methods.
There is no direct binding support such as this (though you could add support). Instead, watch the XML fragment/file for changes and update the node text. There are so many ways of doing this, however, that it'd be difficult to list them all here.
You could, for example, watch for any changes in your editor (like for a multi-line TextBox handle the TextChanged event). When it changes, rebuild your tree from the XML information in the TextBox. To update just the node who's representation has changed in the XML fragment/file, it would be much more difficult. You could construct a path by recursing up the parent elements and pre-pending the text each time, using the TreeView.PathSeparator to separate each node. Then use that to find the node in the tree and update only that TreeNode. This would get increasingly difficult for added and removed nodes because you would also have to take state into account. Most implementations I've seen simply refresh the tree, which is apparent for larger XML hierarchies.
Fortunately, for this application I won't have to worry about too many added or removed nodes.
I continued to play around with the functionality I was looking for. The combination of events that gives me the functionality I'm looking for is both KeyUp and Leave. But, I see that TextChanged would work just as well. Thanks.
I set a flag to manage the dirty state of my text box and this seems to work well even when I have a 6mb XML file loaded in the tree.
I was looking for the method that I use to update just a single node in place. As you said, "simply... refresh the tree". Thanks. That works fine.
That is absolutely not supported! No arrays, no strings, ... you'd get the following error:
Type byte, sbyte, short, ushort, int, uint, long, or ulong expected
Hmm however you can combine 2 int16s into an int32 and find the values by doing some bit manipulation (in a function you call to calculate the values based on the int32 of the enum) I think, but that is way too complicated...
If you use a configuration file to publish the types you want remoted, you can use the RemotingServices.Disconnect to stop the object from receiving further messages. See the documentation for that method for more information.
The only other way is to stop the AppDomain in which the WKO is registered. If you're using a Windows Service, you can stop the service both manually using the Services snap-in or the ServiceController class. If you're hosting this in another process, you could create a separate AppDomain and launch an executable that registers the WKO, then when you want to stop it unload the AppDomain using AppDomain.Unload.
One more way that wouldn't unregister the WKO but would keep it from processing requests (which I wouldn't recommend because clients will still see the published WKO) would be to put the interface in a shared library and the implementation of that on the server. Have an internal method that you can call that could do something like set a flag. In each of your interface implementation methods / properties, check that flag and either don't return anything or throw some sort of exception, like NotSupportedException or something. The first two methods are more complete, IMO.
I have just finished creating a C# class library that has public classes available in it, when i include this lib in my test applications it works fine, but when i passed it to the division i wrote it for they complained it will not work. The error they get is as follows:
"An unhandled exception of type 'System.TypeLoadException" occurred in unknown module. Additional information: could not load type"
It then lists the class they are trying to access from my component.
They are adding a reference to an existing C# app, when they create a test app and add it the component works fine.
My question is what does this unhelpful error message mean and how can i fix it?
Any help would be great
Senior Software Architect
National Energy Services Ltd
Visit Us: www.nesltd.co.uk Or: www.nher.co.uk
A TypeLoadException can occur for many reasons. Since each Type is a fully-qualified class name (includes an optional namespace) in an assembly that has a version, culture, and public key token, any change to that assembly would cause an invalid type. For instance, if you compiled your app against version 18.104.22.168 of your library and the library version was 22.214.171.124 and you had no binding redirection configured in your .config file, a TypeLoadException will be thrown.
If the assembly in which the Type is contained is not in the current directory, a path configured in the <probing> configuration section of your .config file, or the Global Assembly Cache (GAC) a TypeLoadException will be thrown.
How can you avoid these problems? For one, stop using automatic versioning (when the AssemblyVersionAttribute contains an asterisk). This was, IMO, a bad addition to .NET because versions are VERY important in resolving assemblies, unlike native DLLs. Automatic versioning for them would've been nice (it was possible through macros) but for .NET assemblies it is bad. You have no control over the assembly versions.
Second, use project references. If you have the source to a project and want to reference the resulting assembly in another project, click on the Projects tab of the Add References dialog and add a reference to the project to be configured as a dependency. This keeps track of the outputs and will compile the same build configuration of each project (Debug, Release, etc.). This also makes sure that any changes in the dependent assembly will cause the that to be recompiled when you compile the assembly that has a that dependency. If you use a file reference, this will not happen automatically. If you continue to use automatic versioning, you should definitely use a Project reference so that any changes that cause the version # to be different will recompile the target assembly which will bind against that new version.
Finally, make sure that all dependent assemblies exist on the target machine. The base class library assemblies will already be present if .NET is installed (and obviously it must be). Make sure the correct version of .NET is installed, too. While each framework is both forward- and backward-compatible, they are not 100% compatible between versions. Things change some times so some Types may be different. Also make sure that any third-party libraries that your libraries reference are also installed into the GAC (so you don't have to worry about resolving assemblies).
Let's say that the panel consists of 8 buttons, first I want to groop the buttons in to two groops(4 * 2), a timer shall then switch between the two groops and by clicking the mouse, the sellected groop then gets grooped in another groop (2 * 2) and the timer switches (sets focus) between the new groop, and so on, until there is only one button left. (In Norway we call this scanning)
Is there an example of somthing like this on the web?
Since my buttons consist of pictures, I need to somehow view the buttons that are set focus on, any idees?
Focus can only be given to one active control. This is universal. By given a control focus, you give it the input focus. You can't input into two controls at once (though you can give the appearance by echoing). All modern OSes are like that.
Now, if you want the groups of buttons to be selected, that's different. Just like in Windows Explorer (or in any other window manager) you an select multiple items, but only one item has the focus. You could extend the Button class and give it a Selected property (a Boolean most likely). In the set accessor, you could flag the control and invalidate it so that next time OnPaint is called you can draw the picture differently to signify that it has been selected (perhaps drawing a rectanglular border using the Bounds rectangle).
Does anybody know how it would be possible to get the current mouse coordinates within a PictureBox control?
If that doesnt make sense, read on. I am playing around with creating a chess game, the board is an image that is placed within a PictureBox. To be able to process piece selections etc I need to be able to retrieve the part of the image this user has clicked on.
At the moment I am using a rather inelegant solution, by using this.location & cursor.location to calculate where the image was clicked.
post.mode = signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
In all the mouse events like MouseDown, MouseMove, and MouseUp events, the MouseEventArgs contains the X- and Y-coordinates of the client in terms of the client. How did you not notice these in your event handlers? Remember to read the documentation for important information. Since this is related to mouse events, start with the Mouse* events in your PictureBox member documentation.
You can also use the static MousePosition property (inherited from Control) to get the screen coordinates of the mouse, then translate those to client coordinates using PointToClient (inherited from Control) at any time:
Point p = Control.MousePosition;
p = myPictureBox.PointToClient(p);
On a side note, most implementations of checkered boards treat each piece as an object and the board as a grid of contains. This makes development much easier by using object-oriented development practices to control how pieces move and where and when to draw pieces. See http://www.csharphelp.com/archives/archive246.html[^] for an example.
I discovered the mouse up event args on the different events a few moments before your reply came in, I like to cover all possible bases and review documentation whilst I speak to peers. I was working with mouseclick events, which does not have the necessary event args, but I shouldnt really have to justify myself. This is after all a tech community, if documentation is the golden solution you extol it to be, why doesnt CP just save the bandwidth and shutdown the tech forums. *breath*
The Game Board itself is OO based. The board object has a GetBoardImage() method which draws a image of the game board using the objects gamedata (a rather large array), this image is then passed to the picturebox.
When I first started playing with this, I did look at grids (and also creating 64 picture boxes/buttons etc ) but for aesthetic reasons I opted for the GDI method, which works surprisingly well.
post.mode = signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
I have read much of the Microsoft advertsing telling me how wonderfull C# is, but as a Visual C++ programmer should I make the change to C#? I have seen many articles about Java and C# but none discussing C++ and C#.
What I really need is someone experienced in C# to tell me what is wrong with it? Is it really as good as MS claim? Does it really speed up developments? What is more difficult to do using C# when compared with using C++?
TWS_Dave wrote: Does it really speed up developments?
TWS_Dave wrote: What is more difficult to do using C# when compared with using C++?
The more you go into system things ,the less you can do with C#,I myself think C# mostly good for bussiness and generral database developing and somethings like that,there are still some features that still only in win32 and a little hard to use in C#. I myself switch from VC++ to C# but it depends on your jobs and your requirements,for example DirectX9.0 has its own .NET version but VC still use for game developing,if I was a game developer didn't do that(at least not very soon),I myself haven't seen any game in C#,so if you say your field of work we can help you more.
TWS_Dave wrote: Most importantly - what do you think of C#?
IMO, C# is a nice language, but it is let down by the primative set of libraries that make up the .NET framework. (primitive compared to what MFC offers) Of course, the framework is improving with each release and eventually it will be the defacto way of developing for windows.
A lot depends on how much legacy code you have in C++. If you have a great deal of time and money invested in a C++ codebase then moving may not be the best thing to do.
I have a lot of legacy apps that are C++/MFC, and I won't be migrating any of those away from C++. I have 10 years worth of development time invested in C++/MFC, so moving to C# will mean a lot of time learning the new language and how to get the best out of it.
I recommend you read the book 'Inside C#' by Tom Archer. This will give you a nice detailed look at the language, which should give you a clearer picture of where it is better than C++ and where C++ still has the advantage.
A lot depends on the kind of applications that you write. If you write a lot of database related applications, then C# is a lot quicker to use than C++. C# and ASP.NET make writing web-apps so much easier too.
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
The biggest difference is that .NET runs under a managed runtime, i.e. the Common Language Runtime (CLR) manages all memory and enforces certain constraints such as code-access security and native function calls. Of course, C/C++ has a runtime but that really provides simple execution.
As someone else mentioned, the base class library - the library that ships as part of the .NET Framework is lacking. This "lack" of functionality is redeemed by being able to P/Invoke (call native functions), control marshaling, and to perform COM interop very well (since .NET is a progression of - not a replacement for - COM).
The most important thing to understand is that C# is just one of many languages used to write .NET applications. All the compilers produce Intermediate Language (or IL, like Java bytecode, if you're familiar with that) except for the VC++ compiler which - with the /clr switch - is capable of create mixed mode assemblies where native instructions are embedded. The IL from any language is still contrained by the Common Type System (CTS) and the CLR and, hence, can be used by any other language that targets the CLR, but there might be some slight differences since some compilers optimize better / differently from language to language, and because some compilers don't support certain conventions in the language (like VB.NET cannot yet support unsigned integers or unsafe contexts).
I would recommend - as someone else hinted - that you don't just jump on board the .NET wagon. Understand the framework first. Also decide if you need to move the application. Remember, you would then have to deploy an average 20 MB runtime to each client and worry about versioning (versions in .NET are actually used to resolve Types whereas with native DLLs they're just for informational purposes).
If you do want to move to .NET development, I do recommend C#. If you already have a large codebase of libraries, you can turn-on the /clr switch in your project options in VS.NET 2002 and higher for your C++ to produce a mixed-mode assembly and use those in your application development, though you should eventually rewrite those libraries in pure .NET using whatever language you like. Managed C++ is still C++ so - as you know - there's a lot of extra code you have to write but not near as bad as C++ because you don't have to worry about memory as long as you use 100% managed code. C# is also syntactically similar to C++ so you shouldn't have too many problems picking it up.
So, when you think about .NET development, don't think of it so much in terms of languages but in terms of the base class library, IL and the CLR, and CTS. The language is just a means to an end, where those ends are almost the same and can be used by any other means (i.e., a library written in C# can be used by a library written in VB.NET which can be written by an appliction written in PERL.NET).
The .NET world is a totally different beast. C# or any of the other langauges are only the least of things. The framework is what has moved me to .NET as much as anything else. I do not remember for sure but it is something like 8,000 class and it is a fully class based framework, no more SDK.
If you are not developing something machine dependant (this includes heavy graphics), I doubt you will find much missing. I have worked with it now for two years and have not had any stoppers.
The C# language is of course my favorite but that comes from a background of twenty years of C/C++, so it is the closest.
There are a few quirks in the langauge, but overall it is okay. Being able to use other modules from VB.NET or others is really nice.
I will warn you though, be prepared to rethink software design in general. There are so many ways of doing things in .NET that it can be time consuming figuring out the best way to go. Now that we can so easily combine networking and software, the scope of our programs are increasing.
Why settle for some silly import of data when you can use a web service and streamline it. Maybe you application is a resource hog, now you can easily spread its tasks over multiple computers with .NET remoting (that actual works ). Now that we can use a lot of the backend of applications for both web and windows application, we have to start thinking even more of reuse of code.
Now, for time savings!! Yep, it has drastically cut down my development time. I do not know about you, but for me I usually run at 25%-40% of the time of application development debugging. This can range from simply null pointers or dll mistmatches up to several days tracking down bugs.
Not with .NET. My debug time has dropped to almost nothing. Maybe 1%-2% of the time I will be debugging. Very trival now compared to the old C++ days. The code is so simple that errors jump in your face quick quickly. Also a huge reduction in coding since I get more done with less, so it is less to debug.
And remember, this is only the first version, 2.0 is supposed to be a lot better
Of course all this will help when Longhorn comes to market