|
Georgi Atanasov wrote: That is my personal opinion of course.
And which is why you can get away being so wrong 
On a little more serious note...
Georgi Atanasov wrote: Java is completely detached from the underlying OS
So? If it works then why not?
Georgi Atanasov wrote: 99% of the controls are wrappers of their Win32 equivalents; you need to know Win32 API in order to create commercial controls
I'm not sure i'd agree; I've created a Office Fleunt Ribbon control library using nothing more than WPF, which i'm happily using in a commercial grade application, with no problems (http://www.codeproject.com/KB/WPF/ribboncontrol.aspx[^], see also CIRIP).
Georgi Atanasov wrote: WPF consumes lot of memory
It's a new technology, and so not full optimised yet; hey if you want to moan about something *new* then why not have a go about the lack of an open and save dialog. I'm sure exactly the same was said of MFC, Swing, etc.
Georgi Atanasov wrote: is not the platform a company, which cares about performance, would choose on...
There are companies using it, admitadly few currently but growing by the day. Yes, performance is shocking until you learn how to use it properly and then it's more than fast enough. Companies in my eyes don't care about performance, they care about cost to produce something that does the job, and from my experience WPF reduces development time (after over 4-5 years of Windows Forms (and Java Swing for that matter) and only <6 months WPF programming).
|
|
|
|
|
OK, basically, they have nothing to do with ICloneable. But if you want to create a copy of a reference type, this type needs to implement ICloneable, whilst in C++, reference types can be both referenced and copied by default and you can define a copy constructor to change the copying process. I think this is solved much better in C++.
|
|
|
|
|
elektrowolf wrote: you can define a copy constructor to change the copying process
Isn't that then just an implementation or rather synatic difference then.
elektrowolf wrote: copied by default
While certainly clever (and a function by the sounds of it I would like in .net), it sounds like it has the potential to be rather dangerous. Consider;
object a contains b contains c part of dataset d
cloning a potentially may be cloning d as well?
|
|
|
|
|
Derek Bartram wrote:
Isn't that then just an implementation or rather synatic difference then.
Yeah, it's an implementation, I think.
Derek Bartram wrote: cloning a potentially may be cloning d as well?
Yeah, for this you have the copy constructors. Then you can only reference the DataSet in the clone. But of course it's dangerous if you forget this..
|
|
|
|
|
Last symester in High school I learned Java. It was so annoying. For our final sumative we had to make a game (We're kids oaky) and due to time constraints I had to work on it at home. At home I have JRE 1.6, at school they have JRE 1.5. Java 1.5 wouldn't display my game properly, it was all screwed up. I like C# way, way better.
|
|
|
|
|
But.. but... it's portable... so it has to be good
|
|
|
|
|
Huh, I don't know Java. But I don't think it's that bad. C# isn't too fast, too. But there are pretty much features in C# now I don't want to miss like (automatic) properties, WPF, LINQ, extension functions,...
|
|
|
|
|
elektrowolf wrote: C# isn't too fast, too
Uh, ***trying not to sound rude***, how inefficiently do you code?
|
|
|
|
|
.. I mean compared to C++. I don't think it's too slow, I've never had problems with C#'s performance, but for some algorithms you need C++.
|
|
|
|
|
elektrowolf wrote: but for some algorithms you need C++.
like what?
Yes, i'd agree there is a slight performance decrease compaired to c++ but it's neglible.
|
|
|
|
|
Thread t = new Thread(delegate()
{
while (keepShowing)
{
this.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, new RefreshDelegate(delegate()
{
if (!(Mouse.LeftButton == MouseButtonState.Released &&
Mouse.MiddleButton == MouseButtonState.Released &&
Mouse.RightButton == MouseButtonState.Released &&
Mouse.XButton1 == MouseButtonState.Released &&
Mouse.XButton2 == MouseButtonState.Released))
{
if (!insideControl)
{
for (int i = 0; i < this.MenuButtons.Count; i++)
{
if (this.MenuButtons[i].PopupMenu != null && this.MenuButtons[i].PopupMenu.IsMouseInside)
{
return;
}
}
keepShowing = false;
}
}
}));
Thread.Sleep(10);
}
this.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, new RefreshDelegate(delegate()
{
this.IsOpen = false;
}));
});
t.Name = "Capture Click Events Thread";
t.Priority = ThreadPriority.AboveNormal;
t.Start();
A thread with anonamous delegate to a dispatcher with an anonamous delegate.... crazy talk I say. I don't remember exactly where it is (hence I havn't posted it), but I have a thread with anonamous delegate to a dispatcher with an anonamous delegate to a thread with anonamous delegate to a dispatcher with an anonamous delegate somewhere. *Ps. It's in the RibbonControl library, oops (http://www.codeproject.com/KB/WPF/ribboncontrol.aspx[^])
|
|
|
|
|
Yeah, that looks like abuse.
|
|
|
|
|
It's the way forward 
Still, it's a shame they didn't go back to the ways of .NET 1 where you could just directly modify gui properties directly. I remember seeing the justification for it, but frankly .NET 1 never gave me any problems so why change it.
|
|
|
|
|
Nothing really wrong with that... maybe you are just scared of nested closures You should probably stay away from any functional language in that case 
|
|
|
|
|
I'd question perhaps how maintainable that is though!
|
|
|
|
|
I don't even know the code that belongs to and it is rather easy to see what it does. It needs a delegate to invoke back to the GUI thread from within the runner thread. As an exercise, convert that code to a non-anonymous delegate way, you will see the resulting code will be much more disconnected, and a lot more verbose. Unless he is repeating the code anywhere else, I see no reason to refactor it.
|
|
|
|
|
leppie wrote: you will see the resulting code will be much more disconnected
Certainly, however convert it to the .NET 1.0 way and it'll be far less confusing.
|
|
|
|
|
Derek Bartram wrote: I'd question perhaps how maintainable that is though!
The more I think about it, the more I find the answer is very.
All the code is in one place, and isn't abomnably long.
At worst it could be said that the threaded method should be declared rather anonymous, the others are just what anonymous methods were intended for.
I'm largely language agnostic
After a while they all bug me 
|
|
|
|
|
|
I just found a bunch of properties made read-only like this (I think they're from a template):
set
{
}
Huh? If you want it to be read-only, make it read-only! 
|
|
|
|
|
That's not so much read-only as it is a "la la la I'm not listening la la la" property.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? 
|
|
|
|
|
Actually, I have found that sometimes you need to do that.
I can't remember the exact reasoning, but a couple weeks ago I was trying to pass a readonly property to a .NET function of some sort and it would throw an error, despite, the property not being written too...the "fix" was to have an empty set...and I believe I marked it as deprecated so it threw a compile error if someone tried to write to it.
|
|
|
|
|
The ObsoleteAttribute can't be applied to a property accessor. 
The class in question is implementing an abstract class, which specifies both get and set. I should have checked that before I posted this, but still... the set should throw a NotImplementedException or something. Failing that, the accessor should be functional.
|
|
|
|
|
Well, if the guy who owns the interface doesn't want to remove the set from the interface, I guess you are pretty much stucked with that.
|
|
|
|
|
Yes, but silently ignoring the value is poor style.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
