snarfblam

Maybe a mod can clean up my post, the one before, the one after, and this one. This isn't really the thread to have a conversation lumped in the middle of.

Entanglement can't really be used to transmit data any faster than traditional methods. Information cannot be transferred through entanglement. Entanglement can have a "non local" effect (i.e. an action on one particle has an instant (not limited by the speed of light) apparent effect on another, distant particle), but the effect that can be had is very limited. The only effect that can be achieved is that after having examined an (assumed to be random by quantum physics) property of a particle, we know that another entangled particle will reflect that property predictably (non-randomly) and instantly. This can't be used to transmit data, only to provide two, and only two, sets of random data at two different locations, instantly (no matter how far away). Think of entangled particles as read-only. You can have data in two far away places instantly, but you can't inject data into the stream, only read what is already there. An network that employs entanglement only provides encryption that is physically impossible to break, because, similar to issues involved in teleportation, the encryption key can only be observed one time, after which its state is disrupted irrevocably. With entangled particle pairs a random key can be derived from the random quantum states of a particle, which will be reflected identically in each particle in the pair, providing someone on the other end with the only other copy of the encryption key that can ever exist. The data itself must still be sent in a traditional (radio, wire, etc.) method. I'm sure that a lot of people will tell you that entanglement can be used to transmit data instantly, but there are a lot of misconceptions about entanglement. Many people think that entanglement can scientifically define or identify our souls or be used to travel through time. If you pick up a book by a reputable author, however, you will see that what entanglement does is really very limited. All it really does is give us a back door on the apparent randomness of the quantum world.

Visual studio is most likely written in C++. I am almost certain that Windows was. VS must have been programmed in a language with some managed (.Net) functionality because it is fully interactive with the managed runtime environment.

I made a point of excluding metaphysical considerations (souls, consciousness as a non-physical entity, etc.) because any metaphysical aspect of a teleported object would not be teleported, hence you would essentially die, but (not to offend anyone) metaphysics have little bearing on concrete theoretical science (excuse the paradox). It is like believing that taking a photograph will steal your soul. In order for one to consider such a metaphysical belief to have merit, one must be a believer of that metaphysical reality, which makes it particularly impractical to consider in a scientific context. I can make the much simpler argument that a person's identity, inclusive of their consciousness, is a product of person's physical self and that an identical copy of a person would result in the same product, hence the same identity, hence the same consciousness. But then everyone comes back with metaphysical arguments. Cags, I believe you are right. I think individual particles have been teleported. If not, we are not far from it, and the means necessary to do so is certainly known at this point. As far as how teleportation is achieved, it is the destruction of an object and recreation elsewhere. It is the process of reproducing the quantum state (this is important) of an object elsewhere. The reason that an object must be destroyed to be teleported is that, as Heisenberg's Uncertainty Principal says, by observing an aspect of a particle's state the state of that particle becomes altered in such a way that we can not observe other properties that the particle had had at the same time, i.e. the entire quantum state of a particle can not be observed. If you observe the position of an object, it then become impossible to find out how fast the particle was moving. If you observe the speed it becomes impossible to observe the position. If you observe both at once you will get both values, but they each only be half accurate (or one 25% and one 75%, or one 10% and one 90%, there will always be a compromise, though). Essentially the observation corrupts the state of the particle, hence the "destroying" the particle and the object of which the particle is a component. Through the use of entangled particles (see the link in my first post) it becomes possible to observe the entire state of a particle, but the state of the original particle is still corrupted afterwards. A copy of that particle can be re-created elsewhere with the exact same quantum state that the original had, using the information discovered and transmitted via entanglement, but because of limits of quantum mechanics and entangled particles, only one copy can be made and the destruction of the original becomes a necessity. The teleported particle is not actually the same particle (in an �ultimate� sense) but it is the same particle in the sense that it continues the quantum state of the original particle after the original particle�s state is disrupted. Repeat this process over all the particles of an entire object and the entire object is teleported. Scientists generally agree that teleportation of something as complex as an animal would never be practically possible, which makes this discussion purely theoretical. Denaes, your steps 1 and 2 are actually one step. The scanning of the object requires the destruction of said object, and actually also results in half of the reconstruction of the original object. Also, if you prove, using perfect logic of course, that an argument can never be proved or disproved, then that argument is essentially both simultaneously true and false, isn't it? In other words, the truth to an argument becomes irrelevant when it can never have meaning. (Or are we getting into metaphysics again?) I say that identical objects swap places freely and you say that they don't. Well, whether I'm right or you are right, the ultimate meaning of the universe does not change. Both my belief and your belief result in the same, exact, identical world, down to the teeniest quantum detail. Not even the objects that might be magically swapping places can possibly know the difference. That is the logic from which I derive the conclusion that any two objects that are in identical quantum states are essentially the same object, hence the you before teleportation and the you after teleportation, even though composed of particles that can be observed to be separate particles, are still the same person. I'm not saying that you are the same person after teleportation because you magically swap places. I'm saying that you are the same person because, in a relative manner (and the universe as it is scientifically know is a very relativistic thing), you are the same person. Just because you are separated spatially and temporally doesn't mean that you are not the same person. There is a different instance of you in every instance of the universe, separated temporally and most likely spatially, yet over all those instances that pass by you still consider yourself to be the same person that you were born as. In a way, you are more the same person after teleportation than you are after, for example, sneezing (sneezing results in a change in your relative state, teleporting doesn't). I don't know. Should I be writing a book? I seem to have a lot to say.

It is a VB6/VB8 control, magically missing from version 7 (.Net 1.x).

I hope no one minds a post that has nothing to do with programming. My brother and I are in disagreement as to whether teleportation of a person (metaphysical issues and variables aside) would result in a new, different consciousness (essentially killing the original person) or the same consciousness in a different place. I'm just wondering what other people think. (And I'd like to see people on this increasingly quiet board thinking and interacting.) His argument is that if you teleport a person, since the process of teleportation involves the destruction and then reconstruction of an object, the teleported would observe the world as he knows it end, and then another person will be constructed on the other end with all the memories of the old person and unaware that the original consciousness had ended. My take is that, essentially, any two objects, even people, are the same object if they are in exactly the same state (same particles in the same relative locations with the same velocity/polarity/spin/etc.), even if only for a single instant (think of it as a crazy spin or extension on entanglement). For instance, if two objects (object A and object B), identical down to every quantum detail, are sent (sans teleportation) through space from sender A to receiver A and sender B to receiver B (respectively), maintaining their quantum equality throughout (even if they are temporally separated), it is scientifically impossible to prove that the two objects did not instantly "magically" change places and that receiver A did not actually receive object B, and vice-versa. Likewise, it is impossible to prove that they weren't, at least temporarily, two manifestations of the same object. For all intents and purposes, they are the same object. Since teleportation is a process of reconstructing the quantum state of an object in a different location (with the necessity of destroying the original), the post-teleportation person is the same person, not a new person despite being a replication, hence the consciousness is the same consciousness. It is purely theoretical (and maybe philosophical), of course, especially since, as far as anyone knows, teleportation of complex objects will never be a practical possibility, but does anyone have any thoughts? Or does anyone care?

Where do you want to save the data? Once upon a time an INI was the place to put it. More recently the registry was a great place to put that kind of thing. Now the trendy thing to do would be to use an XML file. A web app should probably use a DB. If you want to keep it simple, though, a plain text file would work. If you want to make it more tamper proof you could run the high score data through an encryption stream. But still, the main question is where do you want to put it. There are tutorials around the net that will go over almost kind of data storage you want to use.

I whipped this up for a small concept game, and decided to polish it up and post it here. It is ideal for simple tile based games. Possible Improvements: More rendering methods (i.e. draw group of tiles, clear control to default tile) More rendering overloads Support for multiple sources Multi-layer support (would involve saving tile indices to re-render lower layers) Optimizations (performance, visual appearance on large operations) I will probably incorporate some of these improvements and re-post later. TileBox.zip

You had some confusion about one thing I said:

Since the operation is so large, I don't think that JIT compiling, assembly caching, or anything like that is going to have signifigant impact on performance, hence the order is not particularly relevant, but to be sure, you really ought to try each method a few times and mix up the order.

Note the MaximizedBounds and RestoreBounds properties. These set/return the bounds that the form will assume in the respective state, regardless of the current state.

It seems that we have too many people answering questions and not enough asking. I answer enough questions here, but I don't ask very many, and without a balance of askers and answerers things are sure to get quiet.

What everyone should realize is that a property is just a function pair. What would you expect if you typed the following code: someForm.get_Bounds().Offset(1, 0); I wouldn't expect it to modify the actual form bounds. Here it is fairly clear that you will be modifying a copy of a form's bounds. That is what you need to expect from a property. Or think about it this way: a form class probably doesn't store it's bounds in a RECT at all. It probably has to retrieve them through the Windows API each time you ask the form for it's bounds, so the RECT object that you call the Offset() function on is clearly not attatched in any way to the form (or any .Net object at all) at the point at which you invoke the function. Think of property getters as read-only. Always. Reference-type properties allow you to modify an object, but the reference returned is read-only. Yes, you can write to the returned value, but the value is immediately discarded from the stack so it can't do any good. One thing that doesn't help the confusion is that in some cases you are allowed to treat properties like fields, such as someForm.Width++; but the fact is that the above code actually implies a property get and then a property set... someForm.set_Width(someForm.get_Width() ++);

The fact is that there are a lot of people who pop into the forum just beginning to learn or at most inexperienced. I happen to have a little experience in C++, so when I made the transition from VB6 to VB.Net it took me about a week, and when I made the transition from VB.Net to C# it took me about a day. For someone who has only VB experience (or worse yet, only VB6 experience), C# looks like Chinese and there is a good chance that they have no idea whether or not their particular version has a particular feature. The only real similar looking code is variable assignment and function invocation. Variable declarations, function definitions, especially properties, and all those scary curly braces don't mean anything to an inexperienced VB programmer. It would be great if there were an option in the profile, right when you joined, where you could specify language and version, but it doesn't appear to be a possibility. I think the ultimate reality is that we just have to deal with it.

If you examine the actual mechanics of the code you are using you will see the problem. Look at the following line of code: myPiece.Bounds.Offset(displacement); When you call a property getter it will get the value and toss it onto the stack, where you can assign it to something else, call a function on it, whatever. This confuses some people because it gets tricky with value type objects. When you call the Bounds property to get a value, a copy of that value is placed on the stack. You then call the Offset method successfully, but that doesn't offset the bounds of the original rect. Once you have that copy it is a completely separate object from the actual field that backs the Bounds property and the compiler and runtime have no way to reflect the changes back in the myPiece object. Instead it offsets the bounds of a copy on the stack which is promptly discarded since you do nothing else with it. I do believe that this would cause a compile-time error in VB.

MrPaul, where do you keep getting these clever solutions from? Unfortunately, the compiler can't be that insightful. It's too bad that the compiler can't infer those logical details, but that would be asking for alot.

The MinimumSize property sets the minimum values for the form's Size property, not the ClientSize property. You can either use a minimum size that is (almost) guarunteed to result in a client size at least one pixel, or you can calculate the minimum allowable size by getting the window border sizes from the SystemInformation class, and adding one to each pair of borders (left border size + right border size + 1 and top border size + bottom border size + 1).

Why not set a minimum size for the form that would prevent the client rectangle from becoming zero-width or zero-height.

I think Nerseus might have meant to put his code into another class, either that or he mis-understood some of your code. Why not load all images statically. It would be very simple. public static class Images{ public static Bitmap Wall = new Bitmap("Images\\wall.bmp"); public static Bitmap Path = new Bitmap("Images\\path.bml"); } Elsewhere, when you need to grab an image, you can grab it from the images class. this.WhateverPropertyOrField = Images.Wall; It provides a very straightforward way to load the images once and use them all around. It is basically an equivalent to using the resource designer in VS 2005/Express.

I would stay away from the PictureBoxArray class if at all possible. It is there strictly for compatability with VB6. The nearest appropriate .Net equivalent would be to create your own array and manually populate it, but if you only need one picture box, you hardly need an array.

I think that the static methods are ideal (depending on circumstances). For instance, you could have the Doku.CreateSuDoku method, the Doku.CreateGoDoku method, etc., plus a general purpose Doku.CreateCustomDoku method that accepts size and character type arguments. These methods would then correspond to the (hypothetical) "New SuDoku"/"New GoDoku"/"New Custom Doku" menu items. This method, I'd say, is the most flexible. Note, however, that this method and an inheritance scheme aren't mutually exclusive. You could create a base class that accepts the appropriate values and derived classes that call base constructors specifying the proper values. The static Doku.CreateXXX methods could call appropriate default constructors for the derived classes. At the same time this approach would be dynamic enough to easily allow the program to be somewhat adaptable by allowing the user to enter a custom Doku.

Bingo. Because a quote doesn't count. I guess the logic is that a quote is something someone else said and doesn't count as your own input. I think that you are stuck. Is the issue that you just want your code to be tidy and sound, or does the conflict actually pose a good probability of manifesting itself?

I believe that Activator requires a System.Type or an assembly qualified type name (string) to create an instance. The easiest way, then, to instantiate a class given only the name of the class is to enumerate through the assemblies that are loaded in the current application domain, and on each assembly enumerate through the defined types, until you find a type whose name matches the name entered by a user. If you already know which assembly this type is located in, you can skip the first step and just enumerate the types in the assembly you want to search. You also need to note that names in compiled IL are not exactly the same as the names in code. The generic list class is listed as something like System.Collections.Generic.List`1, and a nested class, such as ListView.ListViewItem, would be listed as System.Windows.Forms.ListView+ListViewItem. There is no nifty function built into .Net to do this for you (maybe I can whip something up and put it in the code library, but not right now). I'm not sure of exactly what it is you want to do, but if you want to examine the type (i.e. fields/properties/functions/etc.) you don't need to create it. Just use the functions on the System.Type object you obtain. If you need to actually interact with an instance of the object (get a value from a field/property or invoke a method), you can use the System.Type you've obtained to instantiate the object through the Activator class. Hope I didn't hurt your head to bad. If I knew exactly what you were doing, I could slightly more specific help.

That is a great solution when the type parameters will be classes of your own creation: you can guaruntee that even if the two type parameters are the same, they will be able to exhibit two different behaviors as needed, but I would imagine that alot of explicit casting would be needed for the sake of overload resolution, and then there is the bigger issue of a possible need of pre-existing classes that can't comply with the constraints.