snarfblam

Sounded like it just might work, but no dice.

It works just fine for me in C# Express and VB Express. It is kinda something that needs to be there. It wouldn't be reasonable to go into the build settings and change everything around when you are ready to build a release version.

Generics Here is a basic generic definition in VB and in C#. [color=magenta]<VB>[/color] [color=blue]Class[/color] Pair(Of T) [color=blue]Public[/color] One [color=blue]As[/color] T [color=blue]Public[/color] Another [color=blue]As[/color] T [color=blue]End Class[/color] [color=magenta]<C#>[/color] [color=Blue]class[/color] Pair<T> { [color=Blue]public[/color] T One; [color=Blue]public[/color] T Another; } The following are comparison of equivalent constraints. [color=Green]<Type must have default constructor>[/color] [color=Blue]Class[/color] HasDefaultConstructor([color=Blue]Of [/color]T [color=Blue]As New[/color]) [color=Blue]class[/color] HasDefaultConstructor<T> [color=Blue]where[/color] T : [color=Blue]new[/color]() { } [color=Green]<Type must be a reference type (class)>[/color] [color=blue]Class[/color] IsClass([color=blue]Of[/color] T [color=blue]As Class[/color]) [color=blue]class[/color] IsClass<T> [color=blue]where[/color] T : [color=blue]class[/color] { } [color=Green]<Type must be a value type (structure)>[/color] [color=blue]Class[/color] IsClass([color=blue]Of[/color] T [color=blue]As Structure[/color]) [color=blue]class[/color] IsClass<T> [color=blue]where[/color] T : [color=blue]struct[/color] { } [color=Green]<Type must inherit a certain base class>[/color] [color=blue]Class[/color] IsClass([color=blue]Of[/color] T [color=blue]As[/color] SomeBaseClass) [color=blue]class[/color] IsClass<T> [color=blue]where[/color] T : SomeBaseClass { } [color=Green]<Type must implement a certain interface>[/color] [color=blue]Class[/color] IsClass([color=blue]Of[/color] T [color=blue]As[/color] IEnumerable) [color=blue]class[/color] IsClass<T> [color=blue]where[/color] T : IEnumerable { } [color=Green]<Type must inherit or implement a generic type>[/color] [color=blue]Class[/color] IsClass([color=blue]Of[/color] T [color=blue]As[/color] IEnumerable<T>) [color=blue]class[/color] IsClass<T> [color=blue]where[/color] T : IEnumerable<T> { } [color=Green]<Example of a combination of constraints>[/color] [color=Blue]Class[/color] HasDefaultConstructor([color=Blue]Of [/color]T [color=Blue]As [/color]{SomeBaseClass, IEnumerable, New} [color=Blue]class[/color] HasDefaultConstructor<T> [color=Blue]where[/color] T : SomeBaseClass, IEnumerable, [color=Blue]new[/color]() { } Note that VB requires the "new" constraint to be the first, whereas C# requires it to be the last. VB and C# both require that "class" and "structure" constraints come first. The "new" constraint can never be used in conjunction with the "class" or "structure" constraint. All three are mutually exclusive ("new" implies a class and "structure" implies a lack of a default constructor) so there is never any conflict between the three when it comes to positioning. In both VB and C#, within code, the generic type parameters are used the same way (i.e. in the same exact manner as any other type).

I can't get the DebuggerDisplay attribute to work in C# express. It works just fine in VB. I searched google and it seems like I'm the only person who has this problem. I can't find any relevant settings or anything. Module Module1 Sub Main() Dim var As New X 'Displays "Test" in the debugger. End Sub End Module <DebuggerDisplay("Test")> _ Class X End Class [CS] class Program { static void Main(string[] args) { X var = new X(); // Displays "{ConsoleApplication2.X}" in debugger } } [DebuggerDisplay("Test")] class X {} [/CS] Anyone have any ideas?

It wasn't said without a sense of humor. And, yes, I'll gladly agree that science will hack out an explanation from time to time to explain what we see well enough to suit our purposes, but that has no bearing on what really goes on in physics. Quantum mechanics tends to ignore gravity, for example, because no one has come up with a satisfactory representation of gravity in the quantum world and the effects of gravity are incredibly small and nearly irrelevant on the quantum scale, but it is obviously still there. Nature is still thoroughly consistent, regardless of our lack of a complete explanation of it. As far as the improbability of human life, that is a very, very subjective thing. Unlikely things do and will happen, even in a very simple and consistent world. And then, life exists because God so desired it. Or life exists because our shortsighted view of the universe does not reveal the inevitability of it. Or (this is my preference) life exists because it is possible. I prefer to believe that anything that can exist will exist, regardless of ultimate representation, but that which could or could not exist is limited in ways that we have no conception of, either due to complexity or obscurity. But there is a lot of theory and philosophy going into that belief. The point is that I believe that the world, when you really get down to it, is a reasonably simple place and if it seems any other way it is only a product of our point of view. That is something that is difficult to argue, either for or against, and what it comes down is that you (or anyone else) have as much right and reason to believe otherwise. We can focus on particular theories, and support them or try to disprove them, but the true nature of the universe is the ultimate enigma that no one can seem to get a handle on.

If there was any confusion between the reality of physics and our understanding of physics then we would all be calling it a day. The entire pursuit of scientific understanding is based on our acknowledgement that our understanding of the world around us is not complete. Quick and dirty hacks are regarded as just that. They will always give a scientist a feeling that something about the theory isn't quite right. And quick and dirty hacks to make a theory functionable are not at all the same as a quick and dirty hack in the actual rules of the physical world. To not make such a distinction, that would be to confuse the ultimate world and our conception of it. I'm no scientist but just like statistical fuzzy quantum mechanics, particles granted with the power to "communicate" in a locality-defiant manner that no other particles can express gives me a feeling that something about the theory isn't quite right. I can't help but think that the two phenomena could be explained by a combined theory that involves a simpler reality. And no, neither of the relativity theories are hacks. One is not a patch for the other. General relativity was theorized because Newton's theory of gravity was not compatible with the theory of special relativity. Don't confuse that as a fix for special relativity. It is a fix for Newton's explanation of gravity. It is not a work-around or a special rule to make things work. Just a more complete theory on the way things work.

I don't know about standard versions, but in VB Express, by default, the solution node is hidden.

Visual Studio does not provide a designer for ContainerControl inheritors. You need to tag your UserControl as a parent control so that the Windows Forms Designer knows your intent to use it as such. How to make a UserControl object behave as a Design-Time control container by using Visual Basic .NET or Visual Basic 2005

As far as the issue of what happens to the body as it is being broken down and teleported, it all depends on how it is done. The particulars of the causality throughout the process are very hard to pinpoint. This is what makes it so difficult to transport a human in the first place (as I have mentioned) which is why this remains a theoretical discussion. At this point I won't deny the possibility of transporting a complex object without disrupting the causality that is essential to the object's being, though. As far as me saying that entanglement defies locality, that is a matter of point of view at this point. No one understands, completely, the hows or whys of the fuzziness of quantum mechanics. Perhaps a second, hidden variable interacts with the probability waves of an electron to produce a product that is the resultant location. Or perhaps the fuzziness is only an illusion created by some sort of underlying mechanics. We say that entanglement defies locality, but that is based on the belief that the mechanics of the quantum world are really, truly, ultimately random and unpredictable. Many scientists believe this to be the case. I prefer to side with Einstein: there must be some sort of underlying variables or mechanics to the situation that we have yet to discover or observe. Attempts at a unified field theory usually try to explain the apparent fuzziness of quantum mechanics because so many people find it so hard to believe that the world would work in such a random, non-sensical fashion. As Einstein put it, "God does not play dice." If Einstein and I are correct, then entangled particles do not really exhibit locality-defiant behavior, but instead, they really are, simply and plainly, equal but opposite reactions. I don't believe that there are magic particles that can defy the most basic rules of behavior governing every other particle. I think, rather, that entanglement simply provides us with a mechanism to peer into the quantum world in ways that we couldn't otherwise. If entanglement really defied locality it would be as though God had made a quick and dirty hack in the rules of physics to make things work.

Syntactically speaking, there is no distinction. The "I" is your biggest clue. Besides that, the base class, if there is one, must be the first in the list. This means that the first item in the inheritance list could be a base class or an interface. Every other one will be an interface. The difference in syntax is the result of a difference in point of view. In a manner of speaking (and as represented in IL), an interface is an abstract class that contains only abstract methods and properties, and in a manner of speaking, you are inheriting each of the interfaces you implement. Your class does inherit all of their functions. An interface is kind of like an abstract class that is very restrictive for the sake of allowing multiple inheritance. If you can see it that way, the syntax suddenly seems much more intuitive.

Well, pardon my assumption that you were using the xxxArray components when you said "Control array."

If you are using VS Express, right click the menu and select "Customize". In the commands tab, under the "Build" category, scroll all the way down. There you will find the "Solution Configurations" toolbar item, which you can add to the toolbar.

I tried to make that point, but you made it so much better than I. "We are not static" is a very good way of putting it. When all is said and done, almost none of what we were originally made of is left. Besides our bodies we find our personalities and our very identy to be something transcendant. We are still considered the same person now and twenty years ago even though the matter and the thought that we are composed of are not the same as they were then. They are connected only by a long sequence of events, and what would teleportation be but another event, one that leaves you more who you are than a day of living your life. Our consiousness ends every day, and begins again the next day. I consider myself to be the same person today as I was yesterday. What would transportation be except, at worst, a more transparent end and beginning.

They are there for compatability. I believe that they are deprecated. This means that Microsoft no longer supports them. No updates. No bug fixes. Nothing like that. Most importantly, they are not guarunteed to be around in future version. What's more, for these reasons, most people will stop using them, meaning that if you have questions or want to share code with other people they will be unfamiliar with them. For all those reasons, you should really stay away from anything in the Microsoft.VisualBasic.Compatability namespace. As painful as it might be, the best way to handle dynamic control creation and array-like control access is by manually creating arrays or ArrayListsof controls in code.

GDI+ in .Net 2.0 is faster that in version 1.x in some scenarios, but classic GDI still wins when it comes to performance. It seems that GDI+ seems to take the biggest performance hit when you draw lots of small images. (Try drawing a 256x256 32-bit bitmap from 16x16 8-bit graphic tiles. I wrote my own BitBlt method, in managed code, and it performed at least 100 times better that GDI+. No lie.)

Implementing Interface Members There are differences between implementing interfaces in VB and C#. VB allows you to implement a function of an interface with whatever name and visibility you like. C# only allows either a public method with the same name as the interface's method or an unnamed private method. Sometimes there may be no direct conversion when it comes to interface implementation. [Color=Magenta]<VB>[/Color] [Color=blue]Interface[/color] IExample [Color=blue]Sub[/color] DoStuff() [Color=blue]Sub[/color] DoOtherStuff() [Color=blue]End Interface[/color] [Color=blue]Class[/color] Implementor [Color=blue]Implements[/color] IExample [Color=Green]'Most common scenario: Public/Same name as interface method.[/Color] [Color=blue]Public Sub[/color] DoStuff() [Color=blue]Implements[/color] IExample.DoStuff [Color=blue]End Sub[/color] [Color=green]'Custom name and private visibility.[/color] [Color=blue]Private Sub[/color] RandomName() [Color=blue]Implements[/color] IExample.DoOtherStuff [Color=blue]End Sub[/color] [Color=blue]End Class[/color] [Color=Magenta]<C#>[/Color] [color=blue]interface[/color] IExample { [color=blue]void[/color] DoStuff(); [color=blue]void[/color] DoOtherStuff(); } [color=blue]class[/color] Implementer:IExample { [color=green]// Most common scenario: Implicit Implementation // What method of what interface this method implements is implied by its // name (must be public).[/color] [color=blue]public void[/color] DoStuff() {} [color=green]// Explicit Implementation // This function is private and has no name, and can not be accessed directly, but only // through the interface (you must cast to IExample).[/color] [color=blue]void[/color] IExample.DoOtherStuff() {} }

I hate to be a party pooper. It isn't that I don't think it is possible. It is that, according to all accepted science, theoretical or not, with the exception of entanglement, this sort of instant, zero latency network would not be possible, leaving entanglement as the only current possibility. So let's discuss that. When you try to understand the basics of entanglement (not the mathematical physics, but the principles), you need to pay attention to what science says entanglement can do, not what it doesn't say entanglement can't do. The idea is not to say "well, maybe it can do this" and assume that it is, somehow, someday, possible until science disproves it. That is for science-fiction. What you need to do is look at what entanglement enables us to do (in theory or in practice), and then determine how we can apply that. It can provide random data in two places where the entangled particles have already been distributed there. That doesn't do anything for our ability to communicate, except give us very nifty encryption keys. And it can allow us to duplicate the state of a quantum particle, which, again, does nothing for our ability to communicate. Entanglement, in theory, allows particles to defy locality (locality being the idea that two particles cannot interact at a distance, limiting communication to nature's speed limit), but only in a manner that does not allow us to defy locality. Ultimately, all entanglement really does is give us a back door on the fuzzy nature of quantum mechanics, allowing us to make predictions on part of an entangled pair that we would not be able to make otherwise (Heisenberg�s uncertainty principle). If you think about it, that is all entanglement needs to do to give us unbreakable encryption and (at the speed of light) teleportation: give us a back door on the uncertaintly principle. And besides that, looking at the text you quoted, it is important to note the word "superluminal," faster than the speed of light, not faster than it can be conceived. I'm done pooping on your party. Now I'm going to poop on Cag's. In the scientific community (which I am not part of, just in case anyone thinks that I think I am) people are very careful to properly refer to an idea correctly as a theory, principle, or whatever, for the sake of keeping in mind what a given "fact" really is. As far as what entanglement could be able to do when our understanding changes, like I said, for a given theory, you need to focus on what it can do, not what we say it can't not do. You are right that subscribing to currently accepted science does little for the advancement of science. Speculating at what a rule might not prohibit is very logically unsound, though, and really won't get you anywhere. Questioning particular aspects of a theory might lead to a discovery. Viewing it in a different light can (or we wouldn't have a theory of relativity). Hoping that a certain theory somehow makes a certain action possible, and then trying to figure out how, is hopeless though. But the real problem is that so many people don't understand the real nature of the theories and principles of entanglement. The very essence of entanglement is derived from the fact that physics must maintain certain balances such as the conservation of energy, or more specifically, for every action there is an equal but oppisite reaction. Quantum physics is fuzzy--it doesn't say that when you do this, that will happen. It says that when you look at an electron, has a certain probability of being in a certain area. There is no way to know until you actually check. All the theory of entanglement says is that, because every action has an equal and opposite reaction, you can know where a particle is without actually looking at it by examining another, entangled particle, hence the back door on the fuzzy nature of quantum mechanics. When you look at the heart of entanglement, it really does not provide any kind of mechanism to defy locality. It really has nothing to do with faster-than-light anything. I'm pooped out now. I won't rain on any more parades if it bothers people, but it just kinda gets at me, in an OCD-ish kind of way, when I see misconception. Maybe I'll go get started on that book.

Maybe you should upload some code. It sounds like you have some severe memory management issues. Perhaps you are doing lots of string processing and the garbage collector is not getting a chance to clean up all the old strings (this can, on a very large scale operation, eat a huge amount of memory), or you aren't disposing large objects, or something to that effect. If you upload all of the code in question we could analyze it and possibly identify some issues.

Control arrays are there for compatability purposes. When developing new applications you should avoid using them. Regardless, if you get a reference to a control or any instance-specific object on a form and spawn a new form, the references will still point to an object on the old form. If you are using "default instances" of forms (a feature in VB8), this is sure to become a point of confusion. If you close the form, then show it again, a new instance is loaded, and any direct references to any objects on that form must be updated to point to the new form. Any "indirect references" won't need to be updated. For example: Public Sub Test 'Get a direct reference to the collection of controls on Form2 Dim testControls As ControlCollection = Form2.Controls 'Clear controls through direct reference to control collection (works) testControls.Clear() 'Clear controls through indirect reference (works) Form2.Controls.Clear() 'Create a new Form2 Form2.Close() Form2.Show() 'Clear controls through direct reference to control collection '(WONT work unless you update the reference) testControls.Clear() 'Update the reference. testControls = Form2.Controls 'Now it works. testControls.Clear() 'Clear controls through indirect reference (still works) Form2.Controls.Clear() End Sub I haven't tested the code, or even tried using default instances in VB, but you should get the idea. Hope it helps.

People, strictly theoretically speaking, can be teleported, but at the speed of light at the fastest. It isn't that much more efficient than hopping into a (hypothetical) light speed space ship, but it has the added advantage that it could be done over fiber-optic networks instead of large open spaces. The very first line in the article you posted is this:

Just in case anyone uses a C# for loop in a non-VBish fasion (it can be useful to do it, though it may be bad practice), here is the conversion: [color=blue]for[/color]([i]initializingExpression[/i], [i]terminationExpression[/i], [i]iterationExpression[/i]) { [i]statements[/i] } Each expression, as well as the contents of the loop, may be converted to VB independently, then inserted into the following code listing. [i]initializingExpression[/i] [color=blue]While[/color] [i]terminationExpression[/i] [i]statements[/i] [i]iterationExpression[/i] [color=blue]End While[/color] To show what I mean, here is an example: [color=Green]// C#[/color] System.Collections.IEnumerator e = SomeCollection.GetEnumerator(); for([color=red]bool keepGoing = e.MoveNext()[/color]; [Color=blue]keepGoing[/color]; [color=Purple]keepGoing = e.MoveNext()[/color]) { [color=Sienna]Console.WriteLine(e.Current);[/color] } [color=Green]' VB[/color] Dim e As System.Collections.IEnumerator = SomeCollection.GetEnumerator() [color=red]Dim keepGoing As Boolean = e.MoveNext()[/color] While [color=blue]keepGoing[/color] [Color=Sienna]Console.WriteLine(e.Current)[/color] [color=purple]keepGoing = e.MoveNext()[/color] End While

What dialog box? The FileOpenDialog? Your own? If you are using the FileOpenDialog then you just read the FileName property.

Which version of .Net do you have? This question was asked very recently, and if you have .Net 2.0 then you can use the MaskedTextbox control. If you have 1.x, you can use a third party control (http://www.codeproject.com/useritems/MaskedTextBox.asp) or write you own.

The designer does not support sharing an ImageList between forms. Depending on what you are doing (and what version of Visual Studio you have) you might be able to add the images to the project as embedded resources and share them between forms.

You could create a new Icon object (there is a constructor that accepts a filename). I'm not sure whether an ImageList will accept and Icon object as an image, but if not, you can call the Icon.ToBitmap method, which will turn it into a Bitmap object, at which point you can add it into the ImageList via the Add method.