snarfblam

Cags, if processing the information involves any sort of latency (with the exception of latency in RAM access, I suppose), multiple threads allows you to grab ahold of much more of the CPU's power. While any one processing operation is waiting on something the CPU is ilding away. By introducing multiple threads you can get started on processing an item while others are waiting. When that first item hits a bottle neck, such as our HTTP request, you can get started on another item, and when that item hits the same bottle neck, there is a good chance that the first item will still be waiting, so we start a third thread and get the third item started. The resources aren't being divided, but rather spare resources are being recovered before they are lost. Now, I'm no threading expert, but I know you don't want to dispatch each item to its own thread. CPU usage is not the only resource a thread consumes. If I didn't have a more experienced person to ask, I would stick with a reasonable number like eight threads, because even if you only push your CPU to 10% that is still an eight-fold gain in performance and keeps the resource-usage (threads, open web connections, locked/mutexed items) to a reasonable level. More threads working equals more threads blocking eachother and waiting for resources. I hope that someone who has more experience in the area can give you better help, though, because their two cents will be worth much more than mine.

I have two keyboards and three mice hooked up to my computer (wired/wireless sets). I have never seen an application treat them as separate devices, however the advantage is that although a keyboard can only send so many keys to the computer at a time, with two keyboards you can send twice as many keystrokes (good for emulators, which are, of course, only used in a manner consistent with the law). If there is any way to distinguish the source of the keystrokes, however, you would have to get pretty low level. I do not believe that DirectX can provide this kind of data to you, and I'm nearly positive that Windows API won't. I would say that maybe setting up a hook would be your best bet (although I believe that some anti-virus or anti-spyware software will report system-wide keyboard hooks as key loggers). Not incredibly helpful, but maybe a starting point.

The Application.ProductVersion property returns the AssemblyFileVersion attribute (as opposed to AssemblyVersion attribute). I personally really wish that Visual Studio had an option to automatically increment the build number on each build and make an easy way to increment the revision/minor version numbers. Seems like an obvious, simple feature to me.

Can you set the ContextMenu property through code?

I believe that algorithms can be patented (in USA). A program itself can't be. But don't quote me on that.

If it was previously connected to the main page, it could possibly found on a search engine or in any previous visitor's history, or a link or reference, direct or otherwise, to that page might have been missed when they were removed from the main page. If, for any reason at any time, there wasn't a default web page in a folder, a list of all the files in that folder may be displayed. If the name of the page is just a word it could be guessed. Although the last two are not very likely, it is still not very safe to restrict access to a page strictly by not linking to it. Some hacker with nothing to better to do with his time is likely to cause you some hell one of these days if you do.

I found that if I disable "Unwind the call stack on unhandled exceptions" the debugger display attribute works correctly, along with a number of other minor problems (including the occasional inability to view instance members after an exception because the "this" pointer is not available). I think that this puts certain limitations on when you can edit and continue.

Attach the handler through the IDE (select the text box, go to the properties window, and click the lighting bolt icon, find your event, and select an event handler or double click the event to create a new handler). The code for the handler should probably look something like this (handling certain keys for certain controls in certain versions of .Net can be a pain, though): // I would prefer KeyDown over KeyPress because it works with keys instead of the characters that they represent private void MyTextBox_KeyDown(object sender, KeyEventArgs e) { if(e.KeyCode == Keys.Enter) nextControl.Focus(); }

No. The attributes specify that extra accomodations be made available for COM interop (thunking and marshalling), but this does not affect the behavior within a completely managed environment.

From what I've read after posting, dynamic_cast is closest to VB's TryCast (C# "as" keyword) and safe_cast is closest to VB's DirectCast.

The simple fact is that C++ and .Net mathematical functions only work with real numbers. If you want to deal with imaginary numbers you either need to write your own functions and classes to deal with them or find a third party library. The first option isn't as bad as it sounds. If I were you I would create a ComplexNumber class. You will need to add to this, obvisously. Also, this is a managed class, but there isn't really any need for this if you prefer otherwise (the conversion is easy enough: remove the "ref" keywork, replace hats (^) with stars (*), and use standard C++ functions). ComplexNumber.h #pragma once ref class ComplexNumber { public: [Color=green]// Constructors[/color] ComplexNumber(void); ComplexNumber(double, double); [Color=green]// Actual values[/color] double real; double imaginary; [Color=green]// Mathematical functions[/color] static ComplexNumber^ Distance(ComplexNumber^ a, ComplexNumber^ b); ComplexNumber^ Negate(); ComplexNumber^ Add(ComplexNumber^ a); [Color=green]// It is always handy to be able to show the user the value // so we will want a method to return a string representation.[/color] virtual System::String^ ToString() override ; }; ComplexNumber.cpp #include "StdAfx.h" #include "ComplexNumber.h" ComplexNumber::ComplexNumber(void) { } ComplexNumber::ComplexNumber(double realValue, double imaginaryValue){ real = realValue; imaginary = imaginaryValue; } ComplexNumber^ ComplexNumber::Distance(ComplexNumber^ a, ComplexNumber^ b){ ComplexNumber^ result = gcnew ComplexNumber(); result->real = System::Math::Sqrt(a->real * a->real - a->imaginary + b->real * b->real - b->imaginary); result->imaginary = 0; return result; } ComplexNumber^ ComplexNumber::Negate (){ return gcnew ComplexNumber(-real, -imaginary); } ComplexNumber^ ComplexNumber::Add(ComplexNumber^ a){ ComplexNumber^ result = gcnew ComplexNumber(); result->real = a->real + real; result->imaginary = a->imaginary + imaginary; return result; } System::String^ ComplexNumber::ToString(){ return System::String::Concat(real.ToString(), " ", imaginary.ToString(), "i"); }

Compared to a control, a component is very simple. The biggest difference is that a component does not go on the form physically. It is shown in the component tray in the designer but at run-time it is simply held in a variable. Not having its own window and all of the variables and message processing that are necessary for a control is a resource-saver. More importantly, making a class a component instead of a control makes your intent for the use of the class more obvious. The whole idea behind the component class is that it can be used in a designer, allowing us to do more in the designer and less code writing. It has nothing to do with controls.

I believe that you need to mark classes that will be used in VB6 with the ComClass attribute (and it might be a good idea to use some ComVisible attributes too). You also need to make your assembly visible to COM (apply the ComVisible attribute to the assembly in AssemblyInfo.vb or (in VB8) go to the project settings and under the "Application" tab click "Assembly Information" where you can check "Make assembly COM-visible").

I think a dynamic cast would be the closest to a DirectCast. C-style casts are considered bad practice by many--it is very flexible, but as a result sometimes what exactly it will do is hard to predict. A dynamic cast is the only non-C-style cast that will perform type checking (like any .Net cast). someType someVarialbe = dynamic_cast<someType> (anotherVariable);

Google Search: The first link has the answer. vbSourceCopy is the same as the Windows API SRCCOPY constant. In the future, new questions should generally go in new threads.

The entanglement-based method of teleportation does not require that the same matter be used for reconstruction. It is, however, according the everything we currently know, the only way to completely examine the state of an object at the quantum level. I've already stated why I think it is important to work at the quantum level, but in order to do so we must destroy the orignal. Your "atomic teleportation" might be nifty for StarTrek-style replicators or very precise manufacturing techniques. I just don't want to be stepping on a teleporter pad and hoping that the next thing I hear is "CLEAR!"

Now that I've looked at the code more closely, it definitely seems like the event handler is attatched twice. That you need a variable to count the number of times the handler is called and only run the code the first time shows that the code is being run twice per click (which means the handler must be attatched twice). How do you attatch the event to the handler? Through the designer? In code? Or both?

I'm sorry. You seem to be missing my point altogether. The point is not that if we reconstruct an object from an "atomic point of view" such that the structure and causality are the essentially the same it somehow wouldn't be the same person. I have not said, implied, or implicated that in anything I said. The point is that an "atomic point of view" is not sufficient to describe a relatively complex object (like bacteria, or certain components in ICs). I keep using the word "causality" because it is of utmost importance in teleportation. I started writing a post with example after example after example, but I scrapped it, because all they do is steer the topic off course instead of driving the point home: "atomic teleportation" does not look at the world in enough detail to teleport a human being. Maybe a Lego. Maybe a can of soda. If you try it with a person I have absolutely no doubt that that person will look the same on the other side, but I also have no doubt that that person will come out dead. Maybe, just maybe, if you throw in all kinds of energy scanning and energy pattern reconstruction equipment, the people will come out alive. They will be infinitely lucky if they aren't insane or if they aren't vegetables, or if they don't develop hundreds of cancerous tumors within a week, etc., etc. How can you not see that so many processes are complex beyond the atomic level? And you don't seem to even react to a certain kind of argument I have been making, so I'll make a point of trying this one on you again. Although not formally hypothesized, many believe that certain quantum phenomena, such as, but not limited to, entanglement, may play a necessary role in biology. How can reproduction at an atomic level possibly address this?

Is it possible that the event handler is being attatched to the event twice? Probably not likely, but I'll throw it out there.

None of this is meant to insult or disparage you. It is good to see your brain in gear, and the logic is certainly there, but I can't help but believe that you are drifting into the philosophical end of the pool, and more importantly, that you are not recognizing certain fundamentals for what they are. Like I said before, there is way too much going on in an atom for you to, in practice, say that "an atom is an atom". Two of the same kind of atom with the same electrical state in the same isotope with the same velocity and same position are not the same. Their states at the quantum level will vary and that will manifest itself in the form of different causality. Besides that, if you work in atoms, you have to take other kinds of matter and energy into special account, not just electricity. So many, in fact, that it would be much simpler to work at the quantum level. Not to mention the impossibly difficult task of reproducing these kinds of energy and matter in the reconstructed object accurately. There is also a possibility (no one knows) that certain phenomena such as entanglement might be vital to the workings of aspects of living creatures. Unless you work at the quantum level, you lose many important aspects of the state of an object. I cannot accept your method of teleportation as a possible viable solution, realistically or theoretically, because it is based on the misconception that an atom is some kind of fundamental building block in the world of physics (they are only so in the world of chemistry). Causality will not be maintained. The two steps I listed are making the point that observing the state of the object and reconstructing the object are not two distinct steps in the only method of teleportation that has any scientific backing, and that destruction of the original is not a step but an unavoidable side-effect. And to clarify, this method of teleportation, at current, has only been used to teleport single quantum particles, where the definition of "teleport" is to entirely reproduce the relative state of the object at a different location or time. Your concept of teleporting in space doesn't make my brother correct. You don't even address the text you quoted, as far as I can tell. Maybe I completely missed your point. If anything the transcendent nature of our being ("illusion of self-consistency") would make him wrong, undermining his concept of what a consciousness it. I cannot respond to several of your arguments because they depend on "atomic teleportation."

If it is an object that has to be disposed (it implements IDisposable) then you really need to keep a reference to it and call the Dispose method. If the object does not need to be disposed then this is not a big deal. The garbage collector can do its thing. If this is code that will be called a lot (each time a button is clicked is not alot, but maybe if it is done hundreds of times each time the button is clicked) and it is something that is relatively easy to optimize (maybe you can keep a reference to an object and re-use it instead of instantiating one each time, for example) then you might consider using another scheme, but in general I wouldn't worry about it much. It is amazing how many objects are created while your program is running. Relatively simple string manipulation can pump out dozens of objects. Every time an event is raised an object is created to pass information (your "e as EventArgs"). One more object here or there is really nothing.

I know I made a bigger deal out of the conversion of matter to energy to matter than you did, but I did understand that it was only one of a set of possibilities. The real point I was after, though, is that the uncertainty principal is not one that can be set aside, simply by dismissing it or working around it by working on a level that is not subject to the uncertainty principal (atoms). The complete state cannot be observed directly. Entanglement allows us to �duplicate� a particle, but at the necessary cost of the destruction of the original. Maybe, some day very far down the road, we will discover another way, but the world as we (and the best minds on earth) know it simply does not allow a way to duplicate the state of a particle. At best we can transfer it directly to another particle. An implication of this teleportation mechanism is that there is no intermediate processes involved in the transfer. Storage in a computer or any other kind of medium is not possible, so we don't have a "blueprint" we can make copies from. You only get one copy, and if you mess it up you don't get any. Either way you lose the original (so don't mess up). People keep coming up with a list of steps. There really are only two steps: (1) Observe the state of the particle using particles from entangled particle pairs. Half of the state will instantly be represented at the destination in the second particle from the pair. This destroys the particle that is observed. (2) Send the other half of the state of the particle using a conventional method (wire, fiber optics) and use that data to reconstruct the original particle. Not only is this the only method that has ever been performed successfully, but it is the only method for which the mechanics of the process have even been conceived.

The teleporting process as I described it is, theoretically speaking, possible. This means reproducing the state of an object on the quantum level. To do this you need to completely examine the state of each quantum particle, and by doing this you are disrupting the state of the particle, essentially "destroying" it. The object you are teleporting, be it a person or something inanimate, will not be intact when you are done. Teleporting, as you describe it, recording the position of every atom and every electical impulse, adds an enormous amount of complexity. Somehow you would have to examine every atom, including those buried deep inside an object, without significantly disturbing others. Conversion of matter into energy and vice-versa is not an easy task either. It would be incredibly difficult if not impossible to convert energy into a specific isotope of a specific atom (or ion) with the correct energy levels. And then there is the matter of molecules, polyatomic ions, and the like. As far as duplicating the electrical impulse (and very many other kinds of energy), I can't imagine how one could examine these accurately, and then somehow inject them into the reconstructed object on the other side. The problem is that the "atoms as lego blocks," as you put it, is a vast over-simplification of the way the world works. There is much, much more to an atom than its atomic number, and much more to the world than atoms. Put quantum particles in the right place in the right state and nifty things will happen. If you try to put the right atoms in the right place, you better cross your fingers.

My mistake. -Multiple constraints on a type argument should be enclosed in curly braces. -There is no requirement for the order of constraints in VB. Maybe a mod can fix my post. And delete these last three posts.

That isn't really something you can do directly. You could use reflection to enumerate over the properties of an object, copying the properties that don't have a Browsable(false) attribute attatched to them, but how you get that into Excel, I wouldn't know.