|
Scott Dorman wrote: Absolutely. I've learned more details about how the Framework does things related to UI in the last two weeks than I have in several years...and all of it from trial and error.
Yes. The bandwagon believes all these things are easy. In truth it often takes the greatest expertise, ability, and effort to make some of the most simple things work.
Scott Dorman wrote: I've found that there are a lot of things that are going on behind the scenes with the designer experience that don't exactly follow the model Microsoft is espousing for the rest of us.
Absolutely.
Something I think they need to do is make developers document all this stuff, because it is very often only in doing so that you realize what too complicated a world you are building (and never documenting, so that people "don't find" the flaws in it).
The truth is, because of all that is wrong and is never resolved, probably 80%+ of the overhead invested in *good* designs is in all these unnecessary trials. I have right now about 10 weeks in a project I wrote the first time in just a few days. There was nothing wrong at all with the first design. It was perfectly straightforward, and efficient.
But it didn't draw to my standards, and I re-wrote it again and again and again, until I developed an extremely refined/optimized automatically forking (intelligent behavior) method of drawing (still not up to C++ standards, thanks to the expectable inferiority of .Net).
OK, so that's fine. But then there's all these inconsistencies in the development environment... so out of all of it I still have 80%+ of my time in fussing (too nice a word) with stuff that none of us would have to fuss with if the people building the tools built them to the standards that we are building product to.
|
|
|
|
|
Scott Dorman wrote: I've found that there are a lot of things that are going on behind the scenes with the designer experience that don't exactly follow the model Microsoft is espousing for the rest of us.
Yes, and there's where we *all* have to worry about the hidden agendas which might exist. On the surface, all this is exalted as cross platform compatible. But in truth, it is these very inconsistencies which can purposely reduce competitors to dogs perpetually chasing their tails for naught, because *our work* itself is forced to comply with the inconsistencies (merely to work).
When you find you can't fire functions from outer class property accessors when the property class is associated with a TypeConverter, is your code base really written as you would want to write it for MONO?
Not at all.
So are you going to fix it for MONO, and is the promise of platform independence a reality?
Not at all.
And then, we're sacrificing speed and working within this huge extra environment for the ostensible purpose of light resource reliance?
What we really need is to C-sharpify-C++ some... deploy all these libraries from the OS... and realize the speed benefits of today instead of downgrading them (substantially).
|
|
|
|
|
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.
|
|
|
|
|
Damn! It's like we're walking down the same path here.
This is where I developed my alternate scheme of drawing.
I took a hard look at all this, and (believing I'm pretty intuitive about where Anders H likes to go with these design features), I decided to descend from Control so that I could do what I wanted with optimal efficiency. In other words, my interpretation of what they're doing with the external classes which provide further services to given classes, is basically a way of partitioning so that the *whole* class you are using (really) *is* not perceived to be so oversized.
My approach was to build just what needed to be built, and to leave all that extra stuff out of my landscape. Totally custom.
After all, you will probably spend more time wrestling with the huge Cadilac they built than *designing* a Porsche. I look ahead, see too many mysteries or insufficiently documented issues... ambigous issues... hidden workings... all that sort of thing, and (thinking I can build it as well as better anyway) I just tend to dispose of all that stuff that can get in the way.
In the end it comes down to this: If *you* can build it as efficiently as it can be built, then why wrestle with all this ostensibly fancy stuff with the huge footprints, when in the end it's going to slow you down so much that you're 2 steps backward (at least), and you've incorporated an eventual dinosaur that, when *they* change it, your life's work is down the tube again.
I trust my standards better than Microsoft's -- and I've already revisited those lessons far too often.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
