|
Nish - Native CPian wrote:
I hope they bring it out as a Service Pack [which is free] instead of as a new version [which won't be free]
Surely you'll just be using a pirated version anyway 
Michael 
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Michael P Butler wrote:
Surely you'll just be using a pirated version anyway
Pirated versions don’t come free MPB. You gotta pay for them. And if you compare salaries, I pay as much of my monthly salary for a pirated CD, that a regular software guy in most other countries would pay for a legal copy of VS .NET.
Anyway I strongly intend to make some money and get myself a LEGAL MSDN subscription.
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Nish may use some pirated software but his VS.NET CDs ARE originals from Microsoft.
Its just that they were originally given to me and we'll just say that Nish pulled them out of the trash can next to my desk right after I tossed them :P
Come to think of it, I still have another set sitting next to me
Michael P Butler wrote:
"Eureka" is Greek for "This bath is too hot"
Nothing gets you thinking like burning your jewels in the morning. 
James
|
|
|
|
|
James T. Johnson wrote:
Nish may use some pirated software but his VS.NET CDs ARE originals from Microsoft.
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
James T. Johnson wrote:
Nothing gets you thinking like burning your jewels in the morning
Now we know what a jewelhole is!
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
I wonder how useful this feature really is. What advantages do we get for doing UI code in MC++ compared to doing it in C# ?
Michael
"Eureka" is Greek for "This bath is too hot"
|
|
|
|
|
Michael P Butler wrote:
What advantages do we get for doing UI code in MC++ compared to doing it in C# ?
None whatsoever
It is good to see that you are slowly subscribing to my views Mike.
|
|
|
|
|
If the rest of your app is in MC++ you don't have to ship a separate assembly for the UI 
Otherwise there isn't an advantage that I can think of.
James
|
|
|
|
|
James T. Johnson wrote:
Otherwise there isn't an advantage that I can think of.
Some languages are more comfortable. When you do MC++, you don't feel as alienated from real unmanaged life as when you do C#
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Nish - Native CPian wrote:
When you do MC++, you don't feel as alienated from real unmanaged life as when you do C#
I don't feel alienated from it because I have P/Invoke and if I really need to, I know I can just create an assembly in MC++ and do my work there.
James
|
|
|
|
|
James T. Johnson wrote:
I have P/Invoke
James T. Johnson wrote:
create an assembly in MC++
Why go to all that bother just to do C#? What's so appealing about it?
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
For .NET code its a lot cleaner to me. You need to be aware of a few performance tweaks (such as avoiding unnecessary boxing) but over all the syntax is much better.
Which of these do you prefer?
MC++
ptr = *dynamic_cast<__box System::IntPtr*>(arlist->Item[index]); or this
C#
ptr = (IntPtr) arlist[index] However, the code I sent you the other day would convince me to switch to MC++ in a heart beat 
James
|
|
|
|
|
James T. Johnson wrote:
However, the code I sent you the other day would convince me to switch to MC++ in a heart beat
Yeah. That was cool
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Michael P Butler wrote:
What advantages do we get for doing UI code in MC++ compared to doing it in C# ?
None except personal preference. Basically anything you do in C# can be one-to-one mapped in VB .NET
But still lot of people don't do VB .NET.
Similarly some only do VB .NET.
And I prefer MC++.
And I can tell you that it's a cool feeling when you can use an MFC CString alongside a .NET String in the same source file. You cannot do that with C# or VB .NET, can you?
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Nish - Native CPian wrote:
And I can tell you that it's a cool feeling when you can use an MFC CString alongside a .NET String in the same source file. You cannot do that with C# or VB .NET, can you?
Actually, isn't that an ATL string [in] MFC [in] .NET
Rocky Moore
|
|
|
|
|
|
Hi!
I'm writing a cross-platform app using the .NET framework. The bulk of my program is in C# but for performance reasons, I'm had to implement a bit in Managed C++.
My Managed C++ .dll includes a class that implements the IList interface:
...
__property virtual bool get_IsReadOnly();
__property virtual Object* get_Item(int index);
__property virtual void set_Item(int index, Object* value);
virtual int Add(Object* value);
etc.
So, the get_Item/set_Item properties above appear as the Item property in VB.NET and MC++. In C#, it should appear as an indexer (object this[int index]). However, what I get is two methods called get_Item and set_Item.
What's wrong?
|
|
|
|
|
This problem has been reported a few days ago in this same forum by someone else. Apparently MC++ collections are not accessible through C# indexers.
I haven't tried it out yet.
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Its not just MC++ collections that can't be accessible through C# indexers; its that MC++ indexers don't come up in C# as indexers.
I can't figure out why that is; because I haven't looked into it much; maybe I'll revisit that issue now
James
|
|
|
|
|
James T. Johnson wrote:
Its not just MC++ collections that can't be accessible through C# indexers; its that MC++ indexers don't come up in C# as indexers.
I can't figure out why that is; because I haven't looked into it much; maybe I'll revisit that issue now
Puzzling!!!
Nish 
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
It takes the debugger about 10 seconds to start up when debugging mixed managed and unmanaged C++ code. If I set the debugger to "managed only", the application is launched in less than one second. I noticed that the network is very busy during the launching of the debugger when in mixed mode - is there something I can change to get mixed mode debugging to startup faster? Thanks
Chris Hafey
|
|
|
|
|
I have had the same problem. When mixing managed and unmanaged code the debugger is super slow. Sometimes I get so fed up I use Ctrl-F5 and run it non-debugged
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
I hear you. I am soooo sick of this. I need to find a computer running dual processors!!!
|
|
|
|
|
|
I'm writting an app in MC++. One of its class is a collection and I don't know what to do to have indexers in C#.
When I disassemble C# code the indexer function is as follow:
get_Item : class System.String(int32)
I tried to add function like this but I didn't work.
Can somebody tell if it's possible.
|
|
|
|
|
Create a property called Item which takes a common parameter in both its set/get functions. ie
__property System::String* get_Item(int index)
{
....
}
__property void set_Item(int index, System::String* value)
{
....
}I don't see anything that lets you create a C# indexer were the class instance can be treated as an array; I assume if you use the Item property name it allows C# to use it as if it were one.
HTH,
James
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
