snarfblam

You should be able to iterate through all the items (the Items property) using a For Each loop, and join them together into one long string, using whatever you like as a separator, though it will probably be a comma or a new line. How is the ListBox populated? I'm not sure if this would work with a databound ListBox.

Occasionally, I have found the InnerException property of a thrown exception very handy in the past when debugging. It might not serve much purpose in a distributed release build of an application, but it can help explain why an exception is being thrown during the development and debugging of an application. I personally do not validate a lot of input for the sake of avoiding redundancy. I have a strong tenancy to not check array bounds because the CLR already does this for me, but I often catch the array bounds exception and throw my own Exception that better describes the situation. In this specific case it might not help a whole lot, but any time I catch an exception and throw another I specify the inner exception in case it helps explain what is going wrong. Suppose there was a hypothetical SerializationFailed exception for a class that serialized data to a file. Checking the inner exception might reveal that a file does not exist, or that it is read-only, or that the user does not have permission to a folder. Classes like Exception really make me wish that there were a way to inherit constructors because it certainly is a pain, and hardly worth the effort, to write and re-write all of the constructor overloads there are for some classes. Since we don't have the luxury, though, we'll have to stick with alot of copy and paste code for our exceptions.

Sometimes errors are thrown and caught completely within DotNet Framework code. The big idea behind exceptions is that you can have an error and try handle it gracefully. That is what is happening here. An exception is being thrown by DotNet code and being caught before it reaches back to your code. Since the exception is neither fatal nor unhandled you are not supposed to have to worry about it. In the real world, though, you do have to worry about it a little bit, because exceptions can slow things down, and there is usually a noticable lag the first time an application throws an exception. Story time. One time I found that there was a noticable lag when I populated a ListView in an application I was writing. A little detective work revealed that this lag only occurred when I was using visual styles. Quite curious. After changing some debugger settings (I set the debugger to break on all exceptions, without exception [no pun intended]) I found that the problem was an exception being thrown and caught inside System.Windows.Forms.dll each time I added an item to the ListView. The solution was to call BeginUpdate before adding items and EndUpdate after adding items. I don't know what the moral of the story is, but while the exceptions are almost transparent to you and practically invisible to the end user, it can be good to try to eliminate them anyways. If you are just curious, I think I've answered your question, but if you are looking to prevent the exceptions here is what I recommend you do. I don't know if the option is available on all versions of all lanugages, but try to set the compiler to break on all exceptions. If you are using VB, you might need to disable Just-My-Code (I'm not really even sure what, exactly, that feature does). Then you should be able to look at the stack trace when the exception is thrown and find clues as to the cause.

The UndoEngine is news to me. In the rare occasion that I added undo/redo to an app, I've rolled my own in the past. The model was similar to the UndoEngine, though.

I think it should look like this: [Color=Blue]Delegate Sub[/Color] SetFocusCallback() [Color=Blue]Private Sub[/Color] SetFocus() [Color=Blue]If Me[/Color].SaveCheckBox.InvokeRequired [Color=Blue]Then[/Color] [Color=Green]'Make a cross-thread "recursive call"[/Color] [Color=Blue]Dim [/Color]d As [Color=Blue]New [/Color]SetFocusCallback([Color=Blue]AddressOf [/Color]SetFocus) [Color=Blue]Me[/Color].Invoke(d) [Color=Blue]Else[/Color] [Color=Blue]If [/Color]Me.SaveCheckBox.Checked = [Color=Blue]True Then [/Color]SaveButton.Enabled = [Color=Blue]True[/Color] [Color=Green]'Could also probably be written[/Color] SaveButton.Enabled = [Color=Blue]Me[/Color].SaveCheckBox.Checked [Color=Blue] End If End Sub[/Color] [/Code] It's not tested, but I think that's the idea.

mooman_fl, while it was perfectly adequate to dismiss the Betamax comparison as nearly irrelevant (I don't mean any offense, Nerseus, the analogy did have some merit depending on persepctive), I certainly appreciate the spin you put on the analogy. You make a very compelling point that equates the commercial world with simple physics. You captured in one short phrase what I tried to express over multiple posts and a dozen paragraphs: people simply take the path of least resistance It is naive to think that the TC conflict will be resolved in a manner dependant upon merit and ideals. Everyone seems to have an opinion about something, and the question is, what forces create and mold our opinions. Especially in an age of communication and corporations, in the end it breaks down to marketing and business strategy. Product quality is a surprisingly small factor in a world where people are so quick to believe what they are told by word of mouth (or the television or by a friend who was informed by the television) rather than examining the situation first hand. People have a strong tendency to form alliances with one product when they have no practical reason (and search for reasons after the fact to justify their position), like the VB critic who continues to reject VB.NET as a "real" programming language but would never consider questioning C#'s legitimacy as a programming language until confronted with the fact that the two languages are essentially syntactical variants of the same language. The difference here is that it is not a matter of product quality, but rather a matter of ideals. Regardless, Microsoft is doing an excellent job of presenting TC as a nifty little tool that will stop viruses and prevent a few China-men from stealing Windows. The reality is that this is the ultimate form of job security for Microsoft, and only time will tell whether simple sociological physics will win over a mounting discontentment with Microsoft's direction, but if you are as serious as I am about the concept of Trusted Computing then you owe it to yourself to do something more than discuss it with your fellow discontents. To that end I present a list of common sense tips to keep in mind when emotion directs you to do otherwise: Be nice. Do not insult or disparage TC proponents, the undecided, or the disinterested. Not only is it unnecessary and a bad personality trait, but it will repel people from anti-TC sentiments. Don't go where you are not wanted. Simply put, your efforts could best be spent elsewhere. Explaining to Microsoft employees and enthusiasts why what they're doing is wrong won't get you anywhere. Anti-TC articles should not be published on CodeProject. No one wants to see their programming chat room flooded with an anti-TC rant. Present your case in the appropriate channels. Look for places where you can get people's attention, share your opinion without offending or inconveniencing them, and allow them to ignore you if they so choose. Honesty is you friend. Do not misinform for the sake of "the cause." Don't tell people that Microsoft or the government will watch over their every move and censor content to the degree of the increasingly popular 1984 analogy. Don't pretend that TC has zero merit or that it is fundamentally evil. Not only will you be lying to others, but you will be lying to yourself and you will be dismissed as a zealot. Don't be forceful. Sorry to make an example of you, MrPaul, but your reaction was unmistakable and, what's more, predictable. When I became critical and assertive, you became defensive. Be informed. Some people might have heard some of the concerns expressed by opponents of TC and, based on that alone, declared TC a dangerous and evil foe. Think for yourself and develop your opinion from fact and logic instead of reacting to someone else's emotion. Being educated means that you can give a compelling argument, cite examples, and back up your perspective. It means that you will sound intelligent and reasonable, and therefore much more believable. And, who knows, you might decide that Trusted Computing isn't so bad after all. Opinions are so much better when they are your own. If you haven't noticed, there is a recurring theme above. When you really believe what you're selling, your attitude is positive, and you are polite you will accomplish much more.

Try changing: ____Me.Invoke(d, New Object() {Focus}) to either ____Me.Invoke(d, New Object(0) {}) or ____Me.Invoke(d, Nothing)

With the Draw/FillElipse methods, you specify a bounding rectangle as opposed to a center and a size. So, like GeoManiac said, you need to subtract the radius from the X and Y values.

This sounds like a recipie for race-conditions, hangs, and crashes. I strongly recommend you read a tutorial on thread-syncronizing.

On what line is the exception happening? Have you tried changing the pool parameter?

What is "Focus" in the line: Me.Invoke(d, New Object() {Focus}) If it is not a declared variable then it will refer to the form's focus method, in which case you may be inadvertently invoking it, which you would be doing across threads, hence your error.

If you read up on MSIL (real exciting stuff) you will understand that this limitation is based on the way DotNet implements the event system. Under the hood a class must declare a function to add an event handler and to remove an event handler, and how they store and manage event handlers internally is entirely up to the programmer (in MSIL and optionally C#) or compiler (all other languages). Since there is no standard way to manage event handlers, there is no standard way to read event handlers. Sorry.

THOSE MFSOBs! They stole my deal. Again! I was working on a DotNet based shell, a.k.a. command prompt, that used C-style syntax and supported immediate execution, functional programming (ala Logo), and compilation, and had easy access to most aspects of the computer (hard drive, registry, etc., etc.). And between the Windows PowerShell and F# they have stolen all my ideas. Oh well.

I believe that the XmlDocument is very reasonable with memory and performance. With alot of optimization, a StringBuilder could be made to be faster, or more memory efficient, or possibly even both, but this raises the question of whether or not it is that important to optimize this aspect of your program. How frequently will you be performing this processing, and how many documents will you be processing? How large is your document? Most likely, the method that best represents your intention and makes code the simplest would be the way to go. If you are doing some heavy processing, your best bet might be to try both and see which one works better.

With the amount of information you have provided it is near impossible to diagnose the problem. Are you doing anything unusual with the Form? Any p/invoke? Third party controls? Are you using any kind of multithreading? Timers? Do you have a normal border on your form? It is enabled, right?

The thing everyone, particularly those who are anti-TC, need to realize is that Microsoft is not fundamentally evil. They are a business, and as such, their goal is to maximize capital. Based on this goal, piracy and open software are percieved as threats (for anyone who doesn't like Microsoft, you will be glad to know that according to Wikipedia [PLAIN][business practices: Intellectual Property][/PLAIN] Microsoft has recognized open software, specifically GNU/Linux, as a threat due to its affordability and even its superiority in some respects). Microsoft has also been critisized for the poor security of their software for as long as they have developed an operating system. Given this, TC seems to sound like a magic bullet to Microsoft. But TC critisism, combined with Microsoft's shady business practices of the past make it all too tempting to regard Microsoft as the devil. BiteByter, I'm no huge fan of Microsoft, but a cinematic moment isn't going to win anyone over. I appreciate that you share my opinions, but being over-zealous is just going to cause people to regard anti-TC sentiments as extreme and dismiss them as nonsensical. Do you really want to be lumped in with conspiracy theorists and white supremacists? My primary objection is not with Microsoft. My objection is with the concept of TC, whose biggest proponent happens to be that mammoth software company that everybody loves to hate.

Which language are you using? Well, here is the syntax for dynamic event handlers in VB and C#, in case you aren't familiar. Assuming that there is an event handler already declared by the name of oldObject_Click... [Color=Violet]<VB>[/Color] [Color=Blue]AddHandler [/Color]newObject.Click, [Color=Blue]AddressOf [/Color]oldObject_Click [Color=Violet]<C#>[/Color] newObject.Click += [Color=Blue]new [/Color]EventHandler(oldObject_Click); [Color=Violet]<C# 2>[/Color] newObject.Click += oldObject_Click; You can't, however, read which event handlers are assigned to an event (except possibly by reflection). You can't really write code that says "take the old control and assign its click event handler to my new controls click event." I don't know if there is really a way to do what it sounds like you want to.

If I understand your question correctly, then the answer should be that to perform an action in a thread-safe manner, the action can be wrapped in a public method and invoked. More specifically, you can define a public function in Form1 that will return the value of the combo box, and then use Form1's invoke method to invoke that function in a thread-safe manner.

In retrospect my tone was a little more offensive than I intended, for which I apologize, but regardless of how poorly they were presented, I stand by the points I made. I don't think that you disagree with me out of ignorance. I think you disagree with me for the same reason that most people disagree with anyone: they already have their mind made up. I did not call your opinion ignorant, I called your response naive. I did this because, for the most part, your response made points that I had already addressed. For example, you said that to use TC meant to condone TC when I had already explained why one would use TC despite his distaste for it. Similarly, you stated that the use of something implies trust. That is hard for me to respond to without being critical. A person might drive a car he doesn't trust because he can't afford to have it repaired. A person might work for a company he doesn't trust because he needs money. Surely you can see why someone would use software from a company that he doesn't trust. You question the concept of lock-in, then you ask what is stopping me from switching OSes? The answer is lock-in. How much DotNet code have I written? WMV and WMA files? How much work would it be to find Linux equivalents to most or all of the programs I have? Software I have for certain devices requires Windows to run. Then, like tfowler, I am not given a choice at work. Our software runs on Windows. How about the games I play on Windows? And, like you, I know plenty of people who use Linux, but they run Windows with it side-by-side. Am I one of those people moaning about Microsoft but doing nothing about it? I don't think that I am. This thread is intended to do two things: explain the compaints I made about Vista on the Vista thread, and educate more people about Trusted Computing, which is the most important thing an anti-TC person can do at this point because the general population simply isn't aware. Finally, I will stop buying Microsoft software if and when I find it necessary. I don't think that your assessment of my nature is fair. Finally, I am not asking you to change your mind. But I am not simply sharing my opinion. I am asking you to look at information and examine others' points of view then consider revising your opinion. This is easier said than done. The normal human reaction in this situation is to read something with distrust, dismiss points made for any superfically substantial reason, and ultimately conclude that you were right all along. Why do I say this? Because I've been guilty of it in the past. We all have. Because we have already made up our minds. Or maybe because changing your opinion is admitting you were wrong. I am asking you to be above that. I'm not looking for an argument, and I'm not looking for a feud. If your mind is already made up then we can agree to disagree. If I have offended you then I am sorry. Sometimes it is hard to express your thoughts in a completely neutral manner. Whether you have already tried to put yourself in someone else's shoes or have resolved not to (I do not and can not say which you have done), your mind is made up. Perhaps we simply have different views on fundamental concepts such as what constitutes choice and what constitutes necessity. After all, it is plain that we have different views on the Microsoft's nature, and I'm sure that my "intellectual property is nonsense" stance is hardly popular. I accept that you do not agree with me, so I will be glad that I offered you a different point of view and leave it at that.

ManagementEven... what? Watch your mouth!

I'm surprised by you, MrPaul. You are an intelligent person, but your arguments are naive.

The 1984 argument is a worst-case scenario of censorship, and censorship alone. This does not address the dozen of other perceived threats of TC. And DRM is far from the end of the world. It is here now and its impact is minimal, but DRM is not an issue that is central to TC. Rather it is a demonstration of the concept in a very, very mild form. As far as locking users 100% into a TC situation, a platform can not really be considered TC unless the hardware and software is 100% TC. Any aspect of the computer that is not TC represents a broken link in the TC chain. All components must be in place. The TC world and non-TC world are incompatible. For the most part this aspect of trusted computing is as extreme as it sounds. A non-TC application would not be able to be trusted and TC would break down. The existence of non-TC documents would defeat the purpose of TC, completely circumventing the trusted-computing components of the computer. In a computer containing TC and non-TC components the two would have to be isolated from each other. TC does not mean that friends can't read your e-mails. When you create a TC document you decide what permissions it has. You do not enforce these permissions (a policy server does), hence the fear of a potential censorship issue, but you can make a document fully accessible, so there would be no need for word to save non-TC documents. What's more, on a TC file system, there is no such thing as a non-TC document. Every document has an author, owning application, and permissions (similar to how every folder in NTFS has permissions associated with it). There might be an option to save in a format that other applications can open, such as RTF, but it wouldn't be unimaginable that Word would deny access to .doc files from Open Office (as is, Microsoft tries to make the Word format as difficult as possible to reverse-engineer and implement in open software), and because of the way TC is implemented, on a TC platform it is practically impossible for unauthorized applications to access documents (think of it as Microsoft's silver bullet for the open software movement). You seem to have the wrong idea about how TC will be implemented. It won't be that one day Microsoft will release an operating system that is incompatible with the rest of the world and implements a tyrannical dictatorship over licenses. The transition to TC will be very (very, very) gradual, such that an average user would never notice. In fact, we are already in the process of that transition. DRM lays the foundation of encryption-protected license-based access to data. Fritz-chips are already being included in new computers. TC will probably be implemented in a manner along these lines: The next step would be to integrate fritz-chips into processors (which have already been designed). More and more software would appear that uses this software, and operating systems would introduce TC concepts. Non-TC software could be phased out until eventually it exists only as legacy software and can finally be disallowed without too much ruckus. You can cite a dozen concerns and explain that they are unlikely and impractical outcomes, but that is from a point of view based on current computing. TC will be introduced gradually and computing will evolve. Only one or a few of our concerns would have to be realized for me to find the situation unacceptable.

I wouldn't really call my syntax highlighting "manual." I actually use two programs I've written: one that applies syntax highlighting to C# code with the output in vB code and an RTF-based formatting tool that produces vB code (which I use for VB, not to be confused with vB). I could (and will, if asked) share them, but I should also point out that PHP syntax highlighting will also usually do the trick for C# code. private bool CheckChar(char c) { if(text[chrOffset] != c) return false; chrOffset++; // seek past char return true; }

My Two Cents The first thing that I should say is that a huge factor in our opinions are core beliefs. I take computing and freedom seriously, and I take free computing very seriously. To the typical user TC might mean very little. To me TC is a very big deal. The thoughts expressed above are not my original ideas. Concerns about TC tend to sound paranoid and a natural reaction is to treat TC concerns as something along the lines of conspiracy theory. But I am not unreasonable and unrealistic. I don't expect every possible thing that could go wrong to go wrong. What frightens me about TC is the number of doors it opens. We've only scratched the surface here. I have my own opinions and I don't expect all, or even most, people to agree with them, but it is only fair to explain my thinking. My biggest personal concern about Trusted Computing is control. (Some of you might have heard this from me before). I believe that control of the computer should be in the hands of the user. Period. The problem is that this conflicts with the concept of intellectual property, of which end users are not legally granted control. My reaction to this is that the concept of intellectual property is vastly overrated. This is where I point you in the direction of Google's business model. I think that service should be the key asset in the computing industry. I think that modern technology has rendered the idea of intellectual property obsolete. In the past the availability of communication (or rather, the relative lack thereof) made ideas and concepts a commodity. Today, these things naturally flow freely just like the air we breath. In this age of communication it is absurd to claim ownership of intellectual entities and try to control the flow of ideas. TC forces an unnatural restriction on the flow of information for the sake of profit and control and while the end result has yet to be seen it will probably be less than utterly horrific. It is the principle and motives and possibilities that what are scary. (Plenty of people disagree with me on my opinion of intellectual property. I understand this and I understand why one might value intellectual property and the rights to their original ideas. So, lets just agree to disagree on the topic.) Everyone should form their own opinion, but these opinions should be educated and relevant information should be provided in an unbiased manner (unfortunately, information from unbiased sources or pro-TC sources is exceedingly rare), so although my beliefs and opinions are obviously biased, I am doing my best to present objective information (below). I am glad to discuss the topic and I have an open mind. I just ask that those who put their two cents in do their research too. Reading the information out there will help answer many questions you might have without needing to ask them here. Wikipedia - Trusted Computing Palladium Blog TC FAQ TC Video Q&A: Trustworthy Computing at Five Years (Microsoft) Against TCPA

In a recent thread about Windows Vista I went on a small rant about the Trusted Computing component of this new version of Windows. Now aware of how little attention the Trusted Computing (TC) concept has received in the general public (largely in part of how major software developers downplay its importance) I think it would be best to explain the implications of the TC platform and make myself sound a little less loony. In fact, this topic is actually very thoroughly discussed on multiple blogs, articles, and forums and the vast majority of the discussions are warnings of the perils of TC, so at the very least, I'm not alone. First, I suppose people should understand how the TC platform works and what principles lie behind it. From that we can draw conclusions about what will happen, what may happen, and what won't happen if the Trusted Computing initiative succeeds. How It Works Trusted Computing is an initiative led by major software and hardware vendors such as Microsoft and IBM, called the Trusted Computing Platform Alliance. In current computing the visible extent of TC is DRM protected media such as movies and mp3s, where the user needs a license decrypt and examine content. This is implemented in software, such as Microsoft's Windows Media Player, which requires a license to view DRM protected media. However, hardware is now being released to enforce TC, generally referred to as a "fritz chip." For the time being this is implemented in new hardware as a chip on the motherboard, but the ultimate goal is to have fritz chips integrated directly into CPUs in not only PCs, but consoles, phones, and any computing device. The framework for this already exists and such CPUs have already been designed. They just need to be manufactured and distributed. What does a fritz chip do? The crux of TC is encryption (2048-bit encryption to be specific). The ultimate goal is that all data and software is encrypted and can not be decrypted without licenses and permissions, which are not managed by users, but rather servers controlled by software vendors. This means that documents and programs can not be accessed without permission. In its earliest phases the impact is minimal because TC is not very much enforced, but rather major vendors are implementing necessary hardware and software that will be required to enforce TC. In other words, for now they are just silently putting the pieces in place. The desired outcome is that all hardware and software must be certified TC compliant and that TC will be enforced by law. The TCPA is already pushing for TC legislature. The end result would be that all software, data, and content would require licenses and permissions to be run, enforced in a practically unbreakable manner (embedded directly into your hardware). Consequences It doesn't sound very unreasonable for software vendors to want to be able to enforce licenses, and really, to enforce the law. The danger is in the many, many implications of Trusted Computing. The reality is that TC will irrevocable change the face of computing as we know it, but the change will be rather gradual. We've discussed some of the "pros" of TC, but let us examine the consequences. Lock-In: TC compliant software and hardware will not work with non-TC software in hardware. What's more, TC compliant software can not access non-TC content and non-TC software can not access TC content. The conclusion could be drawn that this would give the user a choice between the TC world and the non-TC world. The computing world, however, is already in a certain state of lock-in. Most businesses use Microsoft operating systems and software for personal computers, and are not willing to change to cheaper or free alternatives because the immediate cost of the switch-over is greater than the short-term savings. On a TC platform, Microsoft software will generate TC content, which means that e-mail, spreadsheets, and word processor documents are access-controlled. Microsoft software will deny access to these documents from non-Microsoft software. This will curtail open software initiatives of all kinds such as Open Office. It will magnify the state of lock-in. Most people will have TC hardware and a TC OS. All software must be TC, and so all content must be TC. The option of using non-TC alternatives is no longer viable, and the state of lock-in is magnified intensely. Censorship: Not black bars across nipples and asterisks in place of F-bombs, but content deemed unacceptable can be blocked out. Even if you already have the content on your computer, when the access policy servers deny you permission you can't access it. What sort of content might be blocked? Pirated software, music, and movies. Anything that a court deems illegal can be censored. All pirate software can be stopped dead in its tracks instantly. Illegal MP3s can be traced, servers can be blacklisted, and distributors can be identified and prosecuted. The issue here is not that the law can be enforced, but that it can be enforced so utterly and invasively. The feeling of privacy is completely diminished. Another aspect of TC is that it will enforce copyright and licensing in a completely robotic, rigid manner. We all regularly break laws and disobey licenses and agreements. We do it when we e-mail an interesting picture or article to a friend. We might distribute a DLL we aren't licensed to with an application that we are licensed to. TC would essentially eliminate this reasonable "fair use" and "casual use" of what will become controlled content. Small Vendors and Open Software: There are major consequences for the computer industry. Presumably all software will have to be TC-certified. The impact might be lesser on general application programming, where developers are only allowed to use TC components to construct their applications and the product can be safely deemed trusted, but TC will hinder the processes of creating, for instance, standards, frameworks, and hardware. For a relevant demonstration, consider Windows Xp, which warns users about installing uncertified drivers for peripherals. Smaller hardware manufacturers (such as the manufacturer of my wireless mouse and my video game controllers) can't afford Microsoft's certification process. Even this has an impact as it causes concern among some casual users when they install this product which is in reality high quality, reliable, and well priced and perfectly safe. Consider the impact when this sort of product is simply not allowed to exist. There is also an impact on open software. Projects such as WINE, MONO, Open Office, and React OS (an open-source OS whose goal is to be 100% compatible with Windows) will all be all but gone since they will not be granted permission to interoperate with software they need to or open documents they are designed to. Then Why Is There So Little Fuss About Trusted Computing? Software vendors downplay the importance of TC by using a slew of euphemisms and near-propaganda. They generally do not discuss the concept in public channels and when they do they discuss how TC will provide users with security and protection against viruses and other malware and unwanted content. The ironic reality is that this is not what the core principles of TC address. TC will not eliminate malware or mal-content, and in some cases may make it easier for software to operate in an undesired manner (for instance, there would be no more pop-up blockers). Trust and Control The term "trust" is intentionally misleading in its ambiguity. While trust is the central pillar of TC, the question is who is trusting who? It ultimately breaks down to control. The idea is not that users trust their computer. Rather, the idea is that software vendors can trust users and their computers to behave as they see fit, hence the control. The goal is that licenses and permissions are enforced in a manner that is practically impossible to circumvent. This sounds reasonable and fair. The threat comes in the implications, some of which were outlined above. One of the biggest concerns with TC is control. Control is taken from the end user and given to major vendors. Vendors don't seek to trust you in the classical sense of the term--to have faith that you will behave as they would like you to behave. This trust is given a new twist: vendors will trust you because you are forced to behave as they would like. In this sense of the word, trust requires control.