|
Well...you are correct. I did exactly that and problem solved. Now my next question. Why? What's different about referencing the dll into the project that makes that work right?
Rob
|
|
|
|
|
Nevermind...still have same problem. Except this time, when I make a change in the DLL project, compile it, then go to the EXE project and pull the changed reference in, compile, the same thing is happening in the property grid as described above as soon as I open the form with the ImageView on it. If I then close out of VS, relaunch VS, and go directly into the EXE project, open the form, it's fine. Close EXE project, open DLL project, make ANY change, compile, close DLL project, open EXE project, pull in new reference, compile, open form, broken. Immediately close VS, relaunch VS, open EXE project, open form, it's fine. There is still definitely a problem here.
Rob
|
|
|
|
|
Finally got the solution. Override the ToString() method of the expandable objects and return String.Empty, or whatever string you wish, I suppose. Apparently when the control is constructed in the designer, each expandable object automatically spits out its ToString() results to the box next to the property name in the property grid resulting in the full type name of the object unless otherwise specified in an overridden ToString() method. My custom ObjectConverters also seem to still work as well.
Rob
|
|
|
|
|
Well...that didn't quite do it. That does away with the full type name appearing there, but the object converters are still broken when I make a change in the dll project, compile, re-open the exe project, open the form with the ImageView on it, and view the property grid for the ImageView. I still have to close out of VS and re-open it for it to not be broken. When it's broken, I get the following error when I type the correct text next to the property name and hit Enter.
Object of type 'WallpaperQuickSelector.Filter' cannot be converted to type 'WallpaperQuickSelector.Filter'.
This is for the Filter object on the ImageView. I get the same for the Thumbnail object for its type:
Object of type 'WallpaperQuickSelector.Thumbnail' cannot be converted to type 'WallpaperQuickSelector.Thumbnail'.
Rob
|
|
|
|
|
I want to access VS's Main Window Context Menu (is that a MWCM, lol). Where in the document model can I add and remove a item to the Cotext Menu?
You can only be young once. But you can always be immature.
- Dave Barry
|
|
|
|
|
Hello,
[VS 2005]
I am using typed datasets. I have 2 datagridView and when I click one GridA it will add a row to GridB. This works fine and the data is saved to the database.
However, the customer wants to add the rows to GridB and save periodically.
I am wondering is there a way to show the rows that have not been saved, and when the user clicks the save button it will change them to a different colour.
So it will commit some rows everytime the user clicks save. The user can add some more rows and they will be displayed in blue. Once the user clicks save all the rows that have just been added will be saved to the database and then change colour to green.
Can anyone point me in the right direction or give me some code example, will be most grateful.
Many thanks,
Steve
|
|
|
|
|
A DataGridViewRow has the DefaultCellStyle Property, which is of the type DataGridViewCellStyle and has the BackColor property.
you can just give it any color you want. It's probably better to add a (hidden) saved/notsaved column to your datagrid or it's source, then only relying on the color. Then you can ovverride the datagrid.Paint method to display the colors.
Visual Studio can't evaluate this, can you?
public object moo<br />
{<br />
__get { return moo; }<br />
__set { moo = value; }<br />
}
|
|
|
|
|
Hi all,
I want to do the following:
Provide an App Server that, amongst other things, creates a set of dyamically generated classes.
Allow a client app (that I develop) to connect to the App Server and retrieve, via a Remoting call, the server's dynamically created Assembly so that the client app can use the classes that the server Dynamically created (via Relection of course).
I've completed the dynamic code generation of a working set of classes within an 'in memory' dynamically compiled Assembly. What I need to know is how to 'serialise' the assembly back to the client in a manner that allows the client to use the classes in that assembly.
The 'Assembly' class is Serializable, so I've tried providing the obvious server side remoting method:
// In the server:
public class ServerClass : MarshalByRefObject
{
public Assembly GetDynamicAssembly()
{
// Return the assembly containing all my dynamically created classes).
return myDynamicallyGeneratedAssembly;
}
}
// In the client:
ServerClass RemoteServerClass = (create Remoted Server Reference);
Assembly dynamicAssembly = RemoteServerClass.GetDynamicAssembly();
The above call to GetDynamicAssembly() fails with an error along the lines of:
"Could not load file or assembly 'd9ee95f9, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."
The 'd9ee95f9' is obviouly the randomly created assembly name for the dynamic assembly and changes each time I try it.
Is it possible to do what I want, and if so how?
Trevor
|
|
|
|
|
i want to read image of the pictureBox as byte array,how do i this work?
|
|
|
|
|
as a last resort:
Bitmap bmp = new Bitmap(pictureBox1.Image);
byte[] buf = new byte[bmp.Width * bmp.Height * 3];
long i = 0;
for(int y = 0; y < bmp.Height; y++)
for(int x = 0; x < bmp.Width; x++)
{
buf[i++] = bmp.GetPixel(x, y).R;
buf[i++] = bmp.GetPixel(x, y).G;
buf[i++] = bmp.GetPixel(x, y).B;
}
|
|
|
|
|
i have a text box witch bindes to a table,i want to save the changed text in the table,how do i this work with binding method?
(with Acceptchange() )
|
|
|
|
|
I couldn't find a good resouce that gives the introduction on about Provider Model, what is it used for and how can one build. Does anybody have a usual link. I searched but getting more confused seems like its a very detail topic but i want to learn first about the basic idea and then drill down in detail afterwards.
|
|
|
|
|
I am building a chat with file transfer support. I use normally the StreamReader and the StreamWriter built over the NetworkStream, but when i want to send data from a file i would like to use NetworkStream directly, to write bytes without encoding/decoding. If i don't use direcly the NetworkStream (convert all my byte[] to char[], then sending, and converting back after receive) things goes fine.
...
NetworkStream networkStream = socketForServer.GetStream();
StreamReader netStreamreader = new StreamReader(networkStream);
StreamWriter netStreamwriter = new StreamWriter(networkStream);
...
//The writer program:
byte[] buf = ...
netStreamwriter.WriteLine(someString);
netStreamwriter.WriteLine(buf.Length);
netStreamwriter.Flush();
networkStream.Write(buf, 0, buf.Length);
networkStream.Flush();
...
//The reader program:
myString = netStreamreader.ReadLine();
size = Convert.ToInt32(netStreamreader.ReadLine());
byte[] buf = new byte[size];
networkStream.Read(buf, 0, size);
...
This does not work, oh it does for the first times (randomly each run) and then unexpected happens, it cuts parts and reader program reads thrashes because of desincronization with the sending program. Is there another way of sending/receiving raw data ? What am i missing...
|
|
|
|
|
OK, I have a class "Dog" with methods play() and Euthanize(). I have a class Child that must be able to "Play" with "Dog", but not "Euthanize" it. I have a class "Vet" that must be able to "Euthanize" "Dog".
I do not want to isolate "Dog" and "Vet" in their own assembly and make "Euthanize" an internal method of "Dog". I also don't want to nest Dog in Vet.
So, How can I enforce these relationships. I do not trust the child to not play vet and "Euthanize" dog, so it must be IMPOSSIBLE for the Child to call "Euthanize" on "Dog".
I don't know if simply giving the child an IPlayable iterface and the Vet an IEuthanizable interface will be restrictive enough as Child could cast IPlayable to Dog and thereby access its "Euthanize" method.
You used to be able to accomplish this with "Friend" classes in C++. There are no friend classes in C#. Am I forced to either put "Vet" and "Dog" in the same assembly and make Dog.Euthanize internal or to nest "Dog" in "Vet" (which doesn't make sense from an object-oriented standpoint because I want classes "Pound" and "PetStore" to be able to create "Dog" objects without any knowledge of the "Vet" class).
Any ideas?
Thanks!
Ian
|
|
|
|
|
Simple. Euthanize() is not a method of Dog, but is a method of Vet, where you pass in a parameter of type Dog. Actually, a better model is if you pass in a parameter of type IAnimal where Dog implements IAnimal. That way, the Vet can't Euthanize(Child), as much as he/she may want to. 
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Does that also prevent the child from doing whatever the vet can do?
if have the vet as:
vet.Euthanize(IAnimal)
and
child.Play(IAnimal)
how do you prevent the child from 'playing Euthanize' with the dog?
Maby I have now lost the concept?
|
|
|
|
|
Your question doesn't fit the code you posted. Unless you code Play to kill the dog, nothing will happen. There is no such thing as PlayEuthanize unless you code the child class to be a sociopath.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave Kreskowiak wrote: Simple. Euthanize() is not a method of Dog, but is a method of Vet, where you pass in a parameter of type Dog. Actually, a better model is if you pass in a parameter of type IAnimal where Dog implements IAnimal. That way, the Vet can't Euthanize(Child), as much as he/she may want to.
I thought about this approach as well. Euthanize() would seem more appropriately placed in the Vet class, I agree. However when a Vet euthanizes a Dog, there needs to be some way to mark the dog as, um, dead. Whatever means a vet has to do this must be hidden from a child.
My thought is that judiciously used interfaces should do the trick here.
|
|
|
|
|
I understand what you are saying, but the vet still has to interface with the dog to kill it, right? What prevents the child from interfacing with the dog in the same manner the vet interfaces it?
|
|
|
|
|
Edmundisme wrote: I don't know if simply giving the child an IPlayable iterface and the Vet an IEuthanizable interface will be restrictive enough as Child could cast IPlayable to Dog and thereby access its "Euthanize" method.
This will sound trite, but the simple answer is to make sure that your Child code doesn't do that.
Interfaces are good for enforcing the kind of contraints you've described; they limit how the outside world views an object thereby constraining what actions you can perform on them. However, if someone (another programmer) is going to abuse the contract you've given them by only exposing your objects through a limited interface... well, they've broken the contract and all bets are off.
Other than that, you could have some type of key that has to be passed to the Euthanize method. Only a vet would posses such a key, so in theory only a vet could euthanize a pet. Just make sure that the key is hidden from the child. 
I'm curious about this problem, however, and will enjoy reading other answers. Hopefully, they will be more helpful.
|
|
|
|
|
Yeah, I was afraid of that. I've been wondering if I've been trying too hard to solve a problem that doesn't need solving. Perhaps using interfaces is enough.
It's interesting that you suggested using a "key". I suggested this option to one of my coworkers but it sounded a bit strange. So, either it's not a strange solution or I'm not the only one with strange ideas!  Is there a pattern that describes this solution?
|
|
|
|
|
Edmundisme wrote: It's interesting that you suggested using a "key". I suggested this option to one of my coworkers but it sounded a bit strange. So, either it's not a strange solution or I'm not the only one with strange ideas!
Edmundisme wrote: Is there a pattern that describes this solution?
I'm not aware of any pattern, but one may exist.
I was thinking, though, if you want to model this so that it's more inline with the Vet/Pet metaphor, maybe instead of some generic "key," you would use a "medicine" object that is passed to Euthanize. And only a vet would have access to the medicine. But the role of the "medicine" object would be the same as a key: An object not obtainable by a child that must be passed to the Euthanize method.
Anyway, erm, as you can see, I'm not at a loss for strange ideas!
|
|
|
|
|
We are actually using a type like you suggest as the key, although it's difficult to explain the details in the pet/vet world because my problem doesn't exactly fit the metaphor. Thanks for your ideas!
|
|
|
|
|
Edmundisme wrote: because my problem doesn't exactly fit the metaphor.
Obviously since a Child would have a Dog instance not an IPlayable instance. In your real problem the Child would have an IPlayable instance and "should not" cast it to Dog since it could be a Cat. Upcasting is indicative of bad design. Languages do not protect against bad design or bad use. A Client should "read" a socket not "close" it, but nothing stops the developer from writing bad code that closes the socket, then he posts a message on CodeProject "Help Urgent why my code not work".
Edmundisme wrote: We are actually using a type like you suggest as the key
I would not advise a Rube Goldberg[^] design as an attempt to thwart bad developers from abusing a good design. Two wrongs don't make a right.
led mike
|
|
|
|
|
Although I agree this approach seems strange, what makes it "wrong"?
Also, this wouldn't be a problem if C# had friend classes or allowed you to make private types at the namespace level. Any idea why the CLR does not allow friend classes or private namespace types?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
