What ways are there to contact me, and when should you use each ....
I've been getting some very helpful comments from several people regarding bugs that they have found in some of my plugins.
Thanks very much BTW.
However the problem with this is that when I fix and of these bugs I have no idea who to contact, since most people comment anonymously ( at least as far as an amail address is concerned)
So I thought spell out the alternative ways of contacting me :)
1.> EMail: RoryBecker AT gmail DOT com
Useful for general "whazup", "Hey there" or "You and your plugins Suck big-time!" type messages. It's also where notifications of your blog comments get forwarded. I'm plugged into this address whether at home or work. So I'll definitely get your message. Please don't spam me though.
2.> Email: RoryB AT DXSquad DOT com
My DXSquad.com email address, donated by the kind folks at DevExpress.
3.> Developer Express Newsgroups (Plugins, Coderush, RefactorPro). If it's related to these forums then feel free to contact me here.
On the flip side I don't want to hijack said forums with a deluge of mails about my plugins (unless they are wonderful endorsements of how my wonderful plugins have singlehandedly saved your life etc)
Also I encourage anyone out there to email me direct at my gmail address just to let me know you're using a plugin of mine :)
Friday, September 29, 2006
Friday, September 08, 2006
DX_Contrib Bugs fixed in version 0.2.1
The latest version of DX_Contrib fixes PaintIt and UnusedVariables.
Yup that's the beauty of library dlls. They can be used to fix or introduce bugs to several apps/plugins at once. In this case lets hope that the net result is more positive than negative. :)
Specifically fixed in version 0.2.1 of DX_Contrib are
These bugs would have affected any plugin attempting to call PaintElementName. Which includes PaintIt and UnusedVariables.
Anyway hopefully we can now resume our <cough/> usual high service. :)
Yup that's the beauty of library dlls. They can be used to fix or introduce bugs to several apps/plugins at once. In this case lets hope that the net result is more positive than negative. :)
Specifically fixed in version 0.2.1 of DX_Contrib are
- An InvalidcastException which was being caused when PaintElementName was instructed to use the OverlayText PaintStyle (and posibly others)
- An attempt to decorate elements even when they were hidden inside colapsed regions. Oops :)
These bugs would have affected any plugin attempting to call PaintElementName. Which includes PaintIt and UnusedVariables.
Anyway hopefully we can now resume our <cough/> usual high service. :)
Wednesday, September 06, 2006
I want Multi-language projects in Visual Studio
I want multi-language projects in Visual Studio and Here's why...
(NB: this post made from a VS 2003/Framewoirk v1.1 point of view)
VB.Net doesn't cut it ..... but then again neither does C#.
The truth is that both languages compete with each other.
I know Microsoft would have us believe that all languages are equal in the eyes of the framework and to some extent, this is true.
But how eay is it to create an application using both C# and VB.Net?
For example one of the nicer features of C# is operator overloading which vb simply does not have. (not in v1.1 anyway)
Likewise there are things which C# does not have. Like a background compiler.
A reasonable ( but by no means comprehensive list of differences exist here :http://www.advisor.com/Articles.nsf/aid/SHERP42
Anyway the point is this...
The languages are different but each have advantages over the other. Now we find that we have J# F# CAML Python Ruby (I have not looked at any of these directly but at least some of them compile to IL)
So why am I forced to pick a language for a project. I have often found myself wishing that I had operator overloading in VB.net but I shudder when I think of moving permanently to c# as I think of all the things that I might loose.
Now i appreciate that VB.Net 2.0 has operator overloading and further introduces the MY namespace (a seperate debate of it's own) but the truth is that these languages will always have things that the other doesn't.
and yet I still need to create a new project in studio, reference the project or the created dll from wherever it needs to be found from, and ensure that these references are maintained for the life of the project. further there are known to be issues in studio where Project A(VB.net) references Project B(c#) references Project C(VB.Net) again.
And so I ask.....
Why can't I have a Multi Language project where language is specified on a per file basis (probably by looking at the extension). The project properties could have a c# page, a vb.net page. in fact one page for any language that whose files might be included.
We used to be able to compile object files from different languages and then link them together to form cohesive dlls and exes.
Give me back my linking :) Automated of course :)
Ok over to everyone else. Just why is this a bad idea? :P
(NB: this post made from a VS 2003/Framewoirk v1.1 point of view)
VB.Net doesn't cut it ..... but then again neither does C#.
The truth is that both languages compete with each other.
I know Microsoft would have us believe that all languages are equal in the eyes of the framework and to some extent, this is true.
But how eay is it to create an application using both C# and VB.Net?
For example one of the nicer features of C# is operator overloading which vb simply does not have. (not in v1.1 anyway)
Likewise there are things which C# does not have. Like a background compiler.
A reasonable ( but by no means comprehensive list of differences exist here :http://www.advisor.com/Articles.nsf/aid/SHERP42
Anyway the point is this...
The languages are different but each have advantages over the other. Now we find that we have J# F# CAML Python Ruby (I have not looked at any of these directly but at least some of them compile to IL)
So why am I forced to pick a language for a project. I have often found myself wishing that I had operator overloading in VB.net but I shudder when I think of moving permanently to c# as I think of all the things that I might loose.
Now i appreciate that VB.Net 2.0 has operator overloading and further introduces the MY namespace (a seperate debate of it's own) but the truth is that these languages will always have things that the other doesn't.
and yet I still need to create a new project in studio, reference the project or the created dll from wherever it needs to be found from, and ensure that these references are maintained for the life of the project. further there are known to be issues in studio where Project A(VB.net) references Project B(c#) references Project C(VB.Net) again.
And so I ask.....
Why can't I have a Multi Language project where language is specified on a per file basis (probably by looking at the extension). The project properties could have a c# page, a vb.net page. in fact one page for any language that whose files might be included.
We used to be able to compile object files from different languages and then link them together to form cohesive dlls and exes.
Give me back my linking :) Automated of course :)
Ok over to everyone else. Just why is this a bad idea? :P
New versions of Plugins
I have released new versions of PaintIt, MoveIt, DeclareIt, UnusedVariables and DX_Contrib
That's right I have released new versions of my plugins.
PaintIt has had it's guts ripped out yanked around and replaced including a new caaching system to help deal with some performance issues.
UnusedVariables has now been altered to depend on DX_Contrib and so allow you the user to pick the decoration style that is used with this plugin.
MoveIt and DeclareIt have both been changed to depend also on DX_Contrib. They have not changed much although some methods previously held in their "Utils/Utility" regions have moved into DX_contrib instead. There may also have been some minor adjustments in other areas. In truth I intend to have a closer look at the functionality in these 2 plugins over the next week or so.
Finally DX_Contrib itself has been updated to veriosn 0.2 (It should be noted that all the previously mentioned plugins now depend on version 0.2.)
I have included more decoration types for the Stylepicker and I have introduced some Element helper methods many of which have migrated from other plugins.
One of the more interesting things in the latest version of DX_Contrib, is a new LanguageElementIterator.
This object takes a Delegate in it's constructor which is then used as an evaluator for each element it passes over. This makes it very simple for you, the plugin developer, to write a CapitalizedVariables or PrivateMethodsWithUnderScoresInName delegate and pass over this list at any point in your code.
This is how the new versions of PaintIt and UnusedVariables generate their caches.
Anyway...download and have fun. (http://www.rorybecker.me.uk/)
Questions? Comments???
Feel free to comment here on the blog and I will try to respond as quick as I can.
If theis blog has a facility for you to monitor comments of a given post (Ala RSS), then I am unaware of it. As such you will have to check back regularly in order to determine if I have responded to you.
Of course you could just leave your email address or just mail me direct ( RoryBecker AT GMail.com)
That's right I have released new versions of my plugins.
PaintIt has had it's guts ripped out yanked around and replaced including a new caaching system to help deal with some performance issues.
UnusedVariables has now been altered to depend on DX_Contrib and so allow you the user to pick the decoration style that is used with this plugin.
MoveIt and DeclareIt have both been changed to depend also on DX_Contrib. They have not changed much although some methods previously held in their "Utils/Utility" regions have moved into DX_contrib instead. There may also have been some minor adjustments in other areas. In truth I intend to have a closer look at the functionality in these 2 plugins over the next week or so.
Finally DX_Contrib itself has been updated to veriosn 0.2 (It should be noted that all the previously mentioned plugins now depend on version 0.2.)
I have included more decoration types for the Stylepicker and I have introduced some Element helper methods many of which have migrated from other plugins.
One of the more interesting things in the latest version of DX_Contrib, is a new LanguageElementIterator.
This object takes a Delegate in it's constructor which is then used as an evaluator for each element it passes over. This makes it very simple for you, the plugin developer, to write a CapitalizedVariables or PrivateMethodsWithUnderScoresInName delegate and pass over this list at any point in your code.
This is how the new versions of PaintIt and UnusedVariables generate their caches.
Anyway...download and have fun. (http://www.rorybecker.me.uk/)
Questions? Comments???
Feel free to comment here on the blog and I will try to respond as quick as I can.
If theis blog has a facility for you to monitor comments of a given post (Ala RSS), then I am unaware of it. As such you will have to check back regularly in order to determine if I have responded to you.
Of course you could just leave your email address or just mail me direct ( RoryBecker AT GMail.com)
Subscribe to:
Posts (Atom)
Posts
