|
Have a look at the WebRequest[^] class or you could use WCF
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I am developing a control that displays a grid of pictures. I want to be able to select a picture by clicking on it, and change its appearance (eg. with a border) to show that it is selected. I have created:
1. a class derived from UserControl that contains a PictureBox for the picture
2. a class derived from FlowLayoutPanel to contain the pictures. This overrides CreateControlsInstance() to return an instance of...
3. a class derived from Control.ControlCollection to contain the picture objects. This overrides the Add(Control value) method in order to add a handler to the Click event of the control being added to the collection. It also contains the click event handler, and this is where my problem lies:-
It seems to me that the logical next step is for the click event handler to identify the control that has been clicked (no problem) and to call its Select() method, which will then alter the appearance of the control as required. The problem is that Control.Select() cannot be overridden. This raises two questions:
Q1: what does Control.Select() actually do?
Q2: how do I implement the change in appearance of the control. Obviously I could just set the UserControl.BorderStyle property from within the click handler in collection class, but surely an object should make its own decision as to how it looks when it is selected.
I can only assume that I've misunderstood something, or am doing it all the wrong way. Can anyone advise?
Dave
|
|
|
|
|
Hi,
Is there a way to build a join query that combains 3 tables?
how i translate this into linq-
SELECT a.au_lname, a.au_fname, t.title
FROM authors a INNER JOIN titleauthor ta
ON a.au_id = ta.au_id JOIN titles t
ON ta.title_id = t.title_id
WHERE t.type = 'trad_cook'
ORDER BY t.title ASC
Can someone please help me?
|
|
|
|
|
I'm not an expert in linq to sql but
it works with objects/lists. Try:
var query = from a in context.Authors
join ta in context.TitleAutors on a.au_id == ta.au_id
join t in context.Titles on ta.title_id == t.title_id
orderby t.Title
select new { LastName = a.au_lname, FirstName = a.au_fname, Titel = t.title;}
I bug
|
|
|
|
|
nope, dosen't work
== replaced by equals
|
|
|
|
|
what's the error message you get?
I bug
|
|
|
|
|
i doesn's get any error,
but query dosen't return the write result.
|
|
|
|
|
hi guys
i wanna a pattern to find number of html control in page
i test this pattern but thers no result:
@"^<\s*["+pattern+@"]{1}\s(\s*\w*\s*\W*\s*\d*\s*)*/>$"
that pattern is a variable that contain like img,input and so on
modified on Sunday, August 15, 2010 4:34 AM
|
|
|
|
|
we happen to have a Regular Expressions forum since a couple of weeks, maybe you better ask there.
|
|
|
|
|
Yeah, what Luc said, also this[^].
|
|
|
|
|
Hello,
Is there some class / library on .net framework that i can use to activate the webCam directly ?
I want to activate the webCam and have the ability to take snapshot in real time.
Thanks for the help.
|
|
|
|
|
|
Hi, all,
I have a class("Parent") that keeps a dictionary of items of another class("Child"), which I am trying to make generic.
I don't want to make Parent generic, but it needs to know the type to pass to the dictionary constructor:
Dictionary _d = New Dictionary(Of String, Child(of ____))
I could just use Object, but that would defeat the purpose.
I was hoping something like:
Type _childType = (typeof constructorParam)
and then...
Dictionary _d = New Dictionary(Of String, Child(of _childType))
...would work. Instead, the compiler says 'Type _childType' is not defined.
I am hoping there is an easy way to do this Thanks!
|
|
|
|
|
I see a lot of syntax here that does not make sense in C#, is this really a C# question?
Anyway, in C#, you can not use typeof(something) as type argument to something generic. Why don't you want to make Parent generic? This seems to be one of the many "I want to do something but I don't want to use the solution"-questions.. If you make Parent<T> generic, often you won't even need to make the type argument explicit, because one of the arguments of the ctor is of type T (at least that's how I read your post).
|
|
|
|
|
Yeah, forgive me, it was psuedocode.
Basically, the answer is that Parent is not generic. Parent objects don't logically come in different flavors, and there is no reason beyond this problem that I would need to make Parent generic. It would also be an implementation nightmare at this stage, and would require making Grandparent and all the other classes that reference Parent objects generic as well.
|
|
|
|
|
Where does that generics-explosion come from? The type must be known somewhere..
Edit: also, a bit more context would probably help.
|
|
|
|
|
This is a base dll; different implementations will need to use the Child objects differently. Only the implementation will know the type. The Grandparent and all the other classes that ref parent objects have no reason to know the type; only Child and Parent's dictionary of Child need to know.
So there's no way to use a type object as a generic param?
The constructor for Parent is really the only appropriate place to do this. I'm not sure what context you're looking for, but I'm happy to provide answers...
|
|
|
|
|
Pete Burkindine wrote: So there's no way to use a type object as a generic param?
There is one way.. through reflection. I really wouldn't recommend that.
Is there a specific reason to avoid making Parent generic? Such as static fields that must be shared across all instances of parent, not just the ones with the same generic type..
This is what you want, right? Except in a way that actually works.
class Parent
{
Dictionary<string, Child<T>> _d;
public Parent(Type T)
{
_d = new Dictionary<string, Child<T>>();
}
}
It's really not much different from this:
class Parent<T>
{
Dictionary<string, Child<T>> _d;
public Parent()
{
_d = new Dictionary<string, Child<T>>();
}
}
ps: syntax colouring appears to be broken.
|
|
|
|
|
I am open to trying the reflection method, if you could possible provide an example...
The problem with making parent generic is that then all the other classes that ref parent objects in the library will need to know what type it is, which means making them all generic as well. Essentially, the entire library would have to be generic just so one class can be. Coding with the library would be a nightmare, since most of the other classes have nothing to do with child objects and there is no logical relationship between them.
It would be like having to instantiate CashRegister(of Cat) objects because your pet store program has a PetList type that needs the type param. The cash register doesn't need to know that; it should be able to work with the, say, count and price fields on the petlist object without needing to know the cat's hair color. If that makes sense.
|
|
|
|
|
What if you give the Child<t> some interface to implement and make a dictionary of that instead? Or Object even. "the rest" can not use Child<t> anyway since it doesn't know T.
Pete Burkindine wrote: I am open to trying the reflection method, if you could possible provide an example...
Bad idea. Avoid reflection at (nearly) all costs.
warning: it's getting really late here, by now I'm probably not making any sense anymore
edit: 3565555 GET!
|
|
|
|
|
The idea behind making it generic was to avoid un/boxing and type conversions, so I don't want to use object (but am). The interface idea is very interesting; I will give that a try.
Can I ask why you are saying to avoid reflection? I've heard that but don't know why that is.
|
|
|
|
|
Pete Burkindine wrote: avoid reflection
Because it tends to be very slow. However, in cases like yours you can do it once and store (cache) the information so repeated accesses are quicker.
On the other hand, generics offer a whole lot more with a lot less trouble.
I'd still want to know why you don't want to go generic.
|
|
|
|
|
Check out some of the other messages in this thread... Basically it involves making the entire library generic just so one class can be... and having to specify the type parameter of that one class to all kinds of objects that have no logical relationship to it.
Parent objects have relationships to many other classes, so making Parent generic means all those classes have to be generic as well. And it makes no sense to describe, for instance, a Rocket<hamster> just because the astronaut's wife has a pet hamster.
|
|
|
|
|
Yes, I saw that, but it's not very convincing.
|
|
|
|
|
Are you saying that there is a way to avoid having to pass that type parameter to all the other classes that would then reference the generic parent objects?
For instance, there would be Granparent<t>, since Grandparent keeps a dictionary of Parent. And grandparent should be potentially allowed to have Parent<t> objects with different params for T. T is specific to the Child and has nothing to do with Grandparent or its relationship to the Parent objects.
And this becomes even less clear as you get farther away from the family tree. There is a whole other set of classes that keep an association to a particular Parent object, but do not in any way need to know T.
|
|
|
|