|
Just returning for a quick thought.
All this layout engine stuff is really (as far as I'm concerned) about double buffering. It is challenging to build your own scheme which gets the benefits of double-buffering. Well, that needs to be qualified -- *when* you have to do some of the things we had to accomplish.
It always comes down to one little trick: For me, it was realizing that I could cause drawing without calling Invalidate() (which I found *not* to support double-buffering across the conditions I needed support for).
|
|
|
|
|
Scott Dorman wrote: The fact that the Parent property is null at runtime is normal as far as I can tell. The other controls and extenders that I looked at also had the same problem. (I'm not 100% sure of this since it has been several days since I looked at that aspect of it, but I'm pretty sure that was the case.)
PS. None of us can be experts on everything, so the thought I pass along here must be declared to be no more than an educated assumption (based on all experience).
In every visual component design project I've seen or been involved in, null != Parent is obligatory to drawing. My thinking then is that your assumption is a dangerous one to build further work upon. In other words, you might very well waste considerable work before you find indeed that this assumption is wrong (which, without exception, is my experience).
I would absolutely get that Parent assigned, or expect the anomalous behavior you are describing. I mean... how can any process draw your label, if it doesn't even know what to draw it on?
|
|
|
|
|
I see your point. If I create a simple form with two controls on it, the Parent property is not set until the call to this.Controls.Add(...). In my code that I use to add the label control, I have a similar line which also sets the parent property.
The code I ended up with looks basically like this:
this.label = this.provider.EnsureLabel(this.control);
this.label.Text = text;
ISite site = this.control.Site;
if (site != null)
{
site.Container.Add(this.label);
}
this.control.Parent.Controls.Add(this.label);
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
You are *exactly* right.
It is in the underlying handler for Controls.Add() that Parent is assigned -- and the scheme of the visual system is based on this interraction.
To replicate that, all you have to do with your label of course is to add it to the Controls array.
|
|
|
|
|
mike montagne wrote: all you have to do with your label of course is to add it to the Controls array.
Yes, I am doing that (last line of my example code), so it seems like that particular issue, at least, has been resolved.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
OK. What appears to be a probable problem here is that your site.Container.Add(this.label) gives one container the responsibility of painting your label. Then you are given this.control.Parent the responsibility of painting (and disposing) your label.
There's a struggle going on there that cannot be resolved, and your behavior is quite surely a result of it.
|
|
|
|
|
One other thing...
I just thought I'd mention this since your assumption reminds me of a very costly error I made recently. I was looking for documentation to resolve what I believe should have been a very simple matter -- something it should have taken only a few minutes to resolve.
Over the years, I've coached myself to do certain things whenever I encounter a difficulty. The thing I usually do here is first step back and abstract my problem to its most simple possible terms: I made an assumption. *IS* it right?
What happens when we *cannot* answer this question with *absolute* certainty is, we can pursue many trails... always having to return to this juncture unless *we just happen* to get it right. The problem *even* with "just happening to get it 'right'" is, we still don't know if we have "done it" *soundly* -- and so it is *still* necessary to return to the juncture and answer the first question *with absolute certainty*.
So, I slap myself good and hard... and bore into that first question to find the absolute answer.
I believe that will best get you wherever you are going.
On the humorous side of this... so what was my costly error recently of just this sort?
Actually, I posted a couple of questions here, and a few people tried to cite general documentation areas (which were further wild goose chases). I was a bit surprised that no one could answer my relatively basic question, but on careful analysis of product documentation I find instead that there is good reason for all of us to be as "inept" as I was to find the answer to this simple issue.
I needed to define a composite control property of a further custom class, and (of course) I wanted that class property to be displayed under a nested node in Property view.
OK. We can all say I must have been stupid, because we all know that you have to write a "TypeConverter" to do this, right?
If that were so, why was the closest thing to an answer an uncontested suggestion to write a ControlDesigner?
Here's the problem. I spent *days* carefully dissecting walkthroughs for the possible deviation I must have inadvertently committed, *even when the walkthroughs didn't even seem to be explicitly addressing my issue*.
(Well, that's "thorough," isn't it?)
Not exactly. Because I ignored my first question: Was my assumption *right*?
What was my assumption?
No search turned up nested node or pointed me to TypeConverter. I *DID* however see TypeConverter, and I did occassionally browse it a bit. But (due to the way it is written), I never saw it provided the behavior I wanted. Nor, in my wildest dreams, would I assume (particularly because no *conversion* of types should be involved whatsoever with what I wanted to do) that a "TypeConverter" would be the one vital instrument of achieving nested node behavior.
So I *assumed* TypeConverter was not a probable avenue.
Indeed, poor documentation and nomenclature both may be said to have led me astray. And too, there are too many such possible issues to explore so exhaustively (which is why documentation needs to be much better than it is), that we can and do regularly resolve so many issues as fast as we could resolve them if many details were better attended to, and if documentation systems were designed as well as they could be.
But still, my problem would have been solved much faster if I had resolved my assumption to definite terms.
|
|
|
|
|
Scott, if you take a look in the Windows Forms section, I answered this particular problem there. Basically, the problem that you are having is one to do with the sequence of events that happens when a form loads. The extender provider is associated with your component before your component is added into the controls collection, so you need to handle the ParentChanged event to capture the control being added in.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete,
Your explanation here is much easier to understand than the one in the Windows Forms section.  I know they both say the same thing, but this one makes it much clearer. Anyway, as I said in my reply to your other message, between your posts and Mike's I was able to get this working correctly. The finishing touches go on tomorrow.
Thanks,
Scott.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Not a problem. I'm glad that I can be clear at least some of the time
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Now that I've declared victory on the extender component, I'm getting ready to tackle creating a custom layout engine. Do you have anything you can point me to as a good reference? This is in a similar state as IExtenderProvider, very powerful and not well documented at all.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Hi all
I have Visual studio 2003 with just c# installed I have to read in a access database and show it using the smart device application. I sort of know how to do it on a normal app but as soon as i enter using System.Data.OleDb It cannot find on the smart device library. Is there way to read in a database and show it using a smart device app.
Can any one help
Thanks
James_Bond
|
|
|
|
|
|
Thanks
But you see this is using System.Data.OleDb; which is not in the smart device library so i need to use something else. if you know how to do it in smart device or someone else please help
Thanks in advance
James_bond
|
|
|
|
|
Abu Syed Khan wrote: The type or namespace name 'WebcamEventArgs' does not exit in the namespace 'WebCam_Capture' (are you missing an assembly reference?)
The compiler cannot find the WebcamEventArgs type. You have to either get hold of the source code of this class and include it in your project or get hold of the dll containing the class and reference this dll.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
Why would somebody vote "1" for this answer? 
Got my "5", to bring it back in shape!
All the best,
Martin
|
|
|
|
|
Maybe the person in question wanted to vote 5, but is not that good at aiming with the mouse
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
I have written a sort routine using IComparable<t>. It is pretty ugly. I looked on this site and others in order to write what I did. I had a tough time getting my head around both IComparable<t> and IComparer<t>. I was hoping someone would know a good website or book that deal with IComparable<t>/IComparer<t> for those who are learning. Thanks
|
|
|
|
|
Take a look at this blog post: http://vaultofthoughts.net/IComparableVsIComparer.aspx[^]
Essentially, IComparer allows you to customize the sort order of a collection by implementing a Compare method that allows you to compare any two arbitrary objects to determine if one is less than, equal to, or greater than the other.
IComparable is usually implemented by types whose values can be ordered (like string and int), but only allows you to compare the current instance with another object using the CompareTo method.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Richter (CLR Via C#, Second Edition) has an interesting little chapter on p. 141.
Its title is, "Changing Fields in a Boxed Value Type by Using Interfaces (And Why You Shouldn't Do This)"
|
|
|
|
|
PS. You find that chapter by looking up IComparable in the index.
|
|
|
|
|
Hi,
Anybody can please help me out in getting the data from two different tables in two different databases.
Thanks in advance.
rr
|
|
|
|
|
AR Reddy wrote: Anybody can please help me out in getting the data from two different tables in two different databases.
If you can get data out of one table in one database then it doesn't take any lateral thinking to extend that two tables in different databases.
You open two connections, and execute two commands and you get two sets of results back.
|
|
|
|
|
Depending on your DBMS, you can just reference a different database. For SQL Server, you can do the following.
USE Database1 GO
SELECT *
FROM Table1
SELECT *
FROM Database2.dbo.Table2
You need to specify [Database].[owner].[Table/object]
Hogan
|
|
|
|
|
I have to get into a single database and dind to a dataset. How Can i do this?
rr
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
