|
I have just started to get my feet wet with .NET (C#) and I just have one question so far...
Whose cruel joke was it to make the Left, Top, Right, and Bottom properties of the Rectangle Object READ-ONLY! 
Yes, I know the X, Y, Width, and Height are writable, but it doesn't do me much good when I am porting some of my C/C++ drawing code that doesn't think in those terms.
Now that I have that of my chest, I feel much better. 
Thanks...
|
|
|
|
|
To make your transition easier could you just create your own rectangle class that falls back on the System.Drawing.Rectangle class when needed? 
If you got really enterprising you could write an implicit operator so it would cast to a S.D.R silently (for using in GDI+ for example).
James
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Good Idea and something I thought about myself.
Although, the code that I am working with at the moment does *allot* of small rectangle adjustments during the drawing and I am a bit worried about what the performance is going to look like under .NET.
I am currently starting to re-think things, and either I am going to change the drawing logic (I doubt) and/or, to fall back and to code up a rectangle variant that allows L,T,R,B adjustments and translate those into X,Y,W,H adjustments *auto-magically*.
Regards
|
|
|
|
|
I have a C++ method in a component that expects a pointer
to a long as one of its parameters (ie. String*, long*,
long, long). When I try to use this method from VB, the
compiler gives me error "BC30657 'method' has a return
type that is not supported or parameter types that are not
supported". I've narrowed it down to the second
parameter. VB has no problem with the other "longs". It
appears that the pointer to the long is the problem. If I
define it as an Int32*, VB is happy. I'd like to be able
to define it as long* so I don't have to re-write some of
the C++ code. Does anyone know what's happening here? Is
there a work around?
Thanks for any help...
|
|
|
|
|
i'm going to assume you mean vb.net
i'm no c++ guy or vb.net guy ( c# is my cup of tea ), but i'm thinking it is because c++'s "long" is not marshaling correctly over to the managed/clr world. what is a "long"? Int32? Int64?
Since it is a pointer to a long... maybe it should be specified as an IntPtr?
But really... if you are planning on making these things public in a managed environment, you should stick to using types which are CTS compliant... and I believe a pointer to a long... isn't
|
|
|
|
|
Andy:
Thanks for the reply. The problem, as I see it, is that .NET does not know how to resolve the "long*" parameter. It has no problem with the other native C++ types (ie. long, int, etc.). It appears to have problems with pointers to these types. I've verified this by looking at the assembly manifest. It shows pointer syntax for the "long*" parameter. For other parameters that are pointers to CTS types, it shows them as references. The work around appears to be that you can only use CTS types anywhere a pointer to a native C++ type is expected. I'm not sure if this a failing of VB.NET, or, .NET in general.
|
|
|
|
|
well...
I wouldn't call it a "failing" per se.
The CTS defines a LCD of Types that languages must support to be .net compliant. using public variables not CTS compliant WILL result in cross-language problems.
Would you call it a "failing" of C++ if it failed to automagically recognize some arbitrary datatype of some other language that targets the clr? I wouldn't. I'd tell the person using that data type in a public interface to wrap up his language's idiosyncracies in a CTS compliant interface.
The reason the clr isn't having a problem with the other non-pointer datatypes nor pointers to reference types, is because there are direct CTS equivalents. A pointer to a Value Type is implemented as a IntPtr, I believe. check out the docs on it here.
|
|
|
|
|
I've been given the task of coming up with a proposal for our .NET strategy. Does anyone know of a place where I can get detailed information comparing C# and VC++.NET, in particular we need to know which language we should default to so that we
a) keep up with the industry
b) get the results we need in the quickest possible time
Development is currently (in the main) in VC++6 with MFC, so VC++.NET seems like the obvious choice to me, but with all the talk of C# I'm really struggling to know which way to turn, any ideas folks? What would you default to and why? 
Dylan Kenneally
London,UK
|
|
|
|
|
Dylan,
I don't know offhand precisely where to look for such information. However, I'm pretty sure you'll find something in the online MSDN Library msdn.microsoft.com/library.
As to which language to choose, it depends on exactly what you intend to do with .Net. Will you be writing clean slate applications or wanting to leverage existing components?
The consensus seems to be that if you're writing brand new .Net apps., and your developers have a C++ background, then you should go for C#. The alternative is Managed C++ but this is really best-suited for wrapping legacy C++ or Com components for the .Net environment rather than new code.
Of course, it may be that you will be moving over to .Net gradually. In which case you may need to adopt a twin strategy - MC++ for leverage, C# for new stuff. But don't be fooled into thinking that because you are C++ developers therefore MC++ will get you results in the quickest time. C# was *designed* for .Net. MC++ has been *adapted* for .Net. You will find C# to be very elegant and easy to pick up. The biggest learning curve is the .Net framework itself rather than any particular language.
If your developers have a Visual Basic background then the jury is still out. VB .Net is sufficiently different from VB 6 that many VB programmers have gone for C#.
Kevin
|
|
|
|
|
Try these URLs
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cscon/html/vclrfgettingstarted_pg.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconfeaturesofmanagedextensionsforc.asp
Kevin
|
|
|
|
|
What advantages are there for using the .NET platform and C#? From what I understand it will not write code for Linux or MAC, C# exists only on Win2K,XP platforms, you can't even write for win98 either. C# uses mile long names with system.windows.form.something.add.more.names.please and a bases for creating file data structures in XML instead of binary code? Doesn't anyone beleive in making files compact anymore? I am trying to decide if I want to buy it or not. I have a lot of addins that I use for VC6, and I understand that they are not compatible with .NET are they? VC6 can write code which I can recompile on Linux, or MAC without a problem. Are they reasons that I am not aware of as to why I would want to switch over ot .NET, C#, and C++.NET?
Nothing is impossible, It's merely a question of figuring out HOW?
|
|
|
|
|
Aqiruse wrote:
From what I understand it will not write code for Linux or MAC
MS has provided the specification so that you can write applications for other operating systems. There are currently 3 projects to create a .NET for *nix, GnuNET (or maybe it was .Gnu?), Rotor, and Mono. I haven't heard of such a project for Mac but there will probably be one with in the next year.
Aqiruse wrote:
C# exists only on Win2K,XP platforms, you can't even write for win98 either.
Incorrect, C# is a part of the .NET platform; the .NET platform is available on NT4, Win2K, XP, Win98, Win98SE, and WinME. Win95 users are SOL.
Aqiruse wrote:
C# uses mile long names with system.windows.form.something.add.more.names.please
using System.Windows.Forms;<br />
.....<br />
TextBox b = new TextBox();
The using statement makes it so that you don't have to type the whole thing out. The reason for such long names is to be clear and to package it up nicely. Its no worse than some of the security API names in the Win32 API.
Aqiruse wrote:
bases for creating file data structures in XML instead of binary code
The whole point is to interact with other programs written in different languages running on different platforms on the other side of the world. XML is the means, if you don't like it you can serialize to binary form if you wish but you take yourself out of the XML WebServices market.
Aqiruse wrote:
Doesn't anyone beleive in making files compact anymore?
Its merely a tradeoff. Interact with a J2EE webservice with almost no code or create a wrapper to interact with it by hand so that you achieve the smallest filesize as possible.
Modems do a great job of compressing text (which XML is) so there isn't much of a reason not to use it.
Aqiruse wrote:
I have a lot of addins that I use for VC6, and I understand that they are not compatible with .NET are they?
Nope, I belive the DOM changed for VS.NET; but any macros you have should come over with only a few fixes.
Aqiruse wrote:
VC6 can write code which I can recompile on Linux, or MAC without a problem.
You must be writing console programs then, because VC doesn't create windows code that can be taken to other platforms, or you are using a third-party windowing library which is not that same as "VC6 can write code...".
Aqiruse wrote:
Are they reasons that I am not aware of as to why I would want to switch over ot .NET, C#, and C++.NET?
That depends on what kind of stuff you are writing. Since you are currently writing VC6 applications you should give Visual Studio.NET Pro a try; I believe MS offers a 120 day trial CD which would give you ample time to experiment a bit with C# and .NET. If you don't like it stick to VC6 or move to VC7 (which has better standards compliance).
James
Sonork ID: 100.11138 - Hasaki
"Smile your little smile, take some tea with me awhile.
And every day we'll turn another page.
Behind our glass we'll sit and look at our ever-open book,
One brown mouse sitting in a cage."
"One Brown Mouse" from Heavy Horses, Jethro Tull 1978
|
|
|
|
|
Thanks for taking the time to explain it to me. Some of the things I had heard, were incorrect then. In VC6 you can write multi-platform code for linux and MAC. You can get the MFC commercial libraies for Linux if you want to go the MFC way. Or there are about 15, (some free some not) platform libraries that work on Windows, MAC, and Linux (wxWindows and FLTK being free) enabling you to write code and then just recompile (From within Linux or MAC) for the other OS's. That allows you to code GUI applications from within your favorite OS, and have them run on other systems as well. I will take a look at the Trial then, and exam further if its something I want.
Nothing is impossible, It's merely a question of figuring out HOW?
|
|
|
|
|
Aqiruse wrote:
You can get the MFC commercial libraies for Linux if you want to go the MFC way.
Who makes those? I've seen something endorsed by Microsoft for Unix, but when I first looked at it they didn't support Linux.
James
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
|
A very good article about exactly what .NET is (and isn't) can be found here:
http://arstechnica.com/paedia/n/net/net-1.html
|
|
|
|
|
Hi,
I have a control and I would like to change its default color in the designer. I wrote this :
[
DefaultValue(SystemColors.Window)
]
public override Color BackColor
{
set { base.BackColor = value; }
}
I get a build error because I can only set a constant in the DefaultValueAttribute.
How can I achieve that ?
Thanks
Nicolas
|
|
|
|
|
In c#,if you want to override the property ,you must override the 'get' and 'set' method all.
If you only override the 'get' or the 'set' method ,then you will get the compile errors.
|
|
|
|
|
Visual studio6 had tools that could show windows message for specific window ,I can't remember the name of it now.Does visual sudio.net has the same thing?
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
I do beleive the name of the program was Spy++, but I dont know if it comes with VisualStudio.NET. The old version would still work though.
--
David Wengier
TAC ad gone wrong: "Don't fool yourself, you're a bloody idiot."
Sonork ID: 100.14177 - Ch00k
|
|
|
|
|
It's still there in VS.NET...
|
|
|
|
|
Now that I have VC6 and VC7 installed on the same machine I sometimes want to debug an exception or assert in VC6 instead of VC7.
How can I add VC6 to the Just-In-Time Debugging module?
Todd Smith
CPUA 0x007 ... shaken not stirred
|
|
|
|
|
Hi gurus,
I'm trying to move my code from Visual6 to .Net but I've a problem regarding the use of IXMLHTTPRequest cos' it's not recongnized anymore. Could somebody have an idea about the new specifications?
Parker John,
Student Developer, Paris France
|
|
|
|
|
Has anyone else experienced the problem that whilst using VS.Net the properties page just stops working. It appears on the menu bar but will not slide out so that you can actually use it.
The only way to get it to work again is to shut down VS.Net and restart it.
Has anyone else had this problem ?
Nic
|
|
|
|
|
Nic Oughton wrote:
Has anyone else had this problem ?
Only in VS.NET Beta 2. Are you using the beta? If so, get the release version and that bug disapears.
One semi-solution I found in VS.NET Beta 2 was to simply make sure that the properties tab never auto-hid itself. I either had it closed, or open, never hidden.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
