|
Nishant S wrote:
Huh? Nope! I won't cater to your STL-is-better-than-MFC whims! No way!!!
That's fine, I guess someone has to be stuck with doing things the hard and ugly way 
Nishant S wrote:
Anyway thanks for that tip on dictionary objects.
Glad to help - I spent some time last night implimenting a typed dictionary if XmlNodes to paths and values, so it was perfect timing.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
I'm still debating this one, I'd like to keep going with doing MFC development (since I think that is likely to do me better with regard to future employment after graduation etc.).
I was originally going to do some data access code in ATL, as well as a few Office add-ins. I am now considering writing these in C#. The add-ins were going to use the data access code to read and write to a data store. Originally, the data access code would've been written in ATL as a COM server, but I am now considering writing it as a .NET assembly registered in the GAC. Thus enabling the same data library to be used by all constituent parts.
The other part is a regular client. At first thought the whole thing was going to be C# based, but I am now considering doing a mixture, with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code (which will be deployed in the GAC).
Does this sound like a decent thing to do? I'm really keen on developing the client with MFC and was originally going to just dive in with ATL and see where I surfaced. However, if I can accomplish the same thing in C# by using .NET assemblies (with a tiny learning curve) why not?
Considering the majority of the client code will be regular C++ based, with only bits for data access using the managed extensions, will I get almost regular performance, and would this ever be a concern anyway?
Thanks,
Paul
|
|
|
|
|
Paul Ingles wrote:
with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code
That's precisely what I did in my N-Track work-time tracking system. That way you can use MFC for all the GUI stuff and you can also use your __gc classes to access the .NET stuff
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Paul Ingles wrote:
Does this sound like a decent thing to do?
It ofcourse depends on the type of application and the intended audience. If you are doing for fun you can do whatever you want to. If only dataaccess componenets are to be written in managed c++ have a look at ADO (or OLEDB consumers templates). If the majority of code is unmanaged and only a small majority is managed I will prefer to have a fully unmanaged solution. However if extensibility is a consideration managed solution may be considered.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
It is going to serve a couple of purposes, firstly give me more experience developing a proper software application (as opposed to programming/software development theory that I've covered at Uni.
Originally, the idea for the application came from my Uncle, who wanted to do something, but didn't know of any existing software package that would do what he needed -- so I took it up as a bit of a part-time project.
I'd imagine that the majority of the code would be unmanaged, and ideally I'd just go with MFC and ATL. However, developing COM servers in ATL appears a little daunting, so I thought about delving into Managed C++.
I prefer the UI functionality in MFC, as well as the stricter Doc/View architecture. However, the .NET framework encompasses all the "other stuff" pretty well (from what I've seen through developing the odd C# app and ASP.NET app), so it seems an ideal solution.
All I've got to do now is pick up a copy of VS
|
|
|
|
|
I've been writing C/C++ for over 20 years now, and never heard the term "Managed C++" until the last few months. What is it? Maybe something to do with .NET? I've been able to manage my C++ code quite well all along now, with archiving the projects onto other computers, using programs like PVCS, etc.
|
|
|
|
|
It has *everything* to do with .NET. .NET provides a managed environment, known as the CLR (common language runtime?), to which every language must be adapted in order to be considered "managed". The CLR provides services such as garbage colletion, etc.
I'm with you, however. In nearly 20 years of C/C++ I've never encounterd a problem with memory management. Memory related bugs are about the most easy to find and to fix. My feeling is that anyone who can't do that is simply going to find some other way to screw up an application even with the CLR holding their hand. I can understand why an application exposed to the internet would need to be more carefully managed memory wise, but otherwise, I don't see much use in it.
"Human imagination has been sculpted by the universe within which it was born" Hmmmm...
|
|
|
|
|
Reverend Stan wrote:
My feeling is that anyone who can't do that is simply going to find some other way to screw up an application even with the CLR holding their hand
LOL well to be honest, without MC++, the app I am writing would have tanked my computer countless times with un-managed memory "leaks" 
I am so used to the VB and even the C# way of declare, use and forget.
Lets hope my MC++ app is not screwed up in some other way huh? 
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
Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!
|
|
|
|
|
|
hi all,
I am confused about the concept of mixing MC++ with normal C++.
If I want to produce a C++ application that is compatible with the .NET framework and compiles to IL and so on .. can I by ANY MEANS use unmanaged C++ in it ? either by wrapping, by just putting it there, by using __nogc, or by any other way ?
if there is/are way/s .. plz. state them.
this is one, the other thing is : is there any free IDE available on the internet that can compile MC++ ? (either has a compiler or uses cl.exe from M$ .NET framework) -- something like SharpDevelop for C# but to use with MC++
thanx
|
|
|
|
|
Anonymous wrote:
If I want to produce a C++ application that is compatible with the .NET framework and compiles to IL and so on .. can I by ANY MEANS use unmanaged C++ in it ?
Yes, in fact you can produce IL without using any MC++ at all. You can compile an MFC/ATL project with the /clr option and it'll produce an IL executable.
Anonymous wrote:
is there any free IDE available on the internet that can compile MC++ ?
None that I am aware of.
Regards,
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Wow ! u mean I CAN compile unmanaged C++ into IL ? why the managed extensions then ?!
what about STL and Standard C++ ?
|
|
|
|
|
Anonymous wrote:
Wow ! u mean I CAN compile unmanaged C++ into IL ?
No; Nish mis-spoke. The /clr switch allows you to use managed extensions in your C++ application. Anything that isn't managed is written as x86 while the managed stuff is written as IL.
There are some weird occurances that happen with regard to using the gcroot template on an unmanged class; but for the most part what I said above is correct.
You can verify this by opening such an application up with ildasm.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
No; Nish mis-spoke. The /clr switch allows you to use managed extensions in your C++ application. Anything that isn't managed is written as x86 while the managed stuff is written as IL.
Yeah, but I didn't totally mis-speak
Take an MFC app. Apply /clr. Compile and build it. Not one line of managed code. Yet it won't run on a machine without the .NET runtime. Dunno why!
The unmanaged code gets compiled to unmanaged code alright. But there is a basic IL stub that is generated. Maybe it does some elementary initialization.
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
With /clr switch the exe/dll automatically creates a dependence on mscoree.dll which is a .NET dll. It won't run without it and you can't delayload mscoree.dll.
Joel Lucsy (jjlucsy@ameritech.net)
|
|
|
|
|
/clr tells the compiler to generate MSIL, or "managed code", which runs in the context of the CLR. Once you compile with /clr, you can consume any managed datatypes, from the .NET Framework, or some other library.
/clr DOESN't take your C++ datatypes and make them "managed data". They're still allocated and destroyed by you, from the C++ or Win32 heap.
To create your own "managed data types" (garbage collected, and consumable by other managed applications) you need to apply some of the managed-extension keywords; primarily __gc.
You can also use #pragma managed and #pragma unmanaged to control within a module what code is compiled to MSIL, and what is compiled to x86.
Nick
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
You are correct. The point, however, was that the /clr switch creates a dependance on mscoree.dll whether or not you use any "managed code/data".
Joel Lucsy (jjlucsy@ameritech.net)
|
|
|
|
|
Ok so I have a MC++ Class Library and it is being called from a C# app. All hunky dory, except I cannot get the class library to write to any files when it is called from the C# app.
I wrote the equivalent code in the C# app and the file was created fine and in the right place.
Am I supposed to be doing something extra to tell the system that the class dll can write files?
The crappy thing is that no error is generated, in fact stepping through each line the system seems to think the file was created just fine. But no file appears.
I am using the XMLTextWriter to write the file. e.g. myXmlTextWriter = new XmlTextWriter (S"test.xml", System::Text::Encoding::UTF8);
I have used Flush and Close, no luck.
So what gives? thanks.
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
Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!
|
|
|
|
|
|
|
I had to look and go through your code to find this out.
1. AfxEnableControlContainer is automatically called by CHtmlView so it is not necessary. But still it is a good practice to have it in the InitInstance.
2. MFC requires AfxOleInit in order for control containment to work and I am surprised to see that in VS.NET it is automatically called during CreateControl. If that fails MFC cannot create controls.
Now to the actual answer.
Activator.GetObject or Activator.CreateInstance initialize COM automatically if it is not initialized and the default is to initialize is COINT_MULTITHREADED. So when MFC tries to call AfxOleInit (COINIT_APARTMENTTHREADED) the call fails because you cannot change the apartment type. So the control creation fails.
But when you call AfxOleInit in InitInstance Activator.GetObject sees that COM is initialized so it doesnot do anything and everything is fine.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
Rama Krishna wrote:
AfxEnableControlContainer is automatically called by CHtmlView so it is not necessary. But still it is a good practice to have it in the InitInstance
Yes, in fact I did not add it myself. The app wiz had put it there for me.
Rama Krishna wrote:
MFC requires AfxOleInit in order for control containment to work and I am surprised to see that in VS.NET it is automatically called during CreateControl
I had looked at the different overloads of CWnd::CreateControl but had not found any call to AfxOleInit, but just now I found that COleControlSite::CreateControl does indeed call AfxOleInit
Rama Krishna wrote:
Now to the actual answer.
Brilliant!!! Thanks
Regards,
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Hey guys 
In my MFC (/clr) app, I can't set breakpoints. I mean I can, but the moment I run it in debug-mode the maroon circle gets a question mark and this message pops up "The breakpoint will not currently be hit. No executable code is currently loaded at this location"
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
|
Hello,
I have an MFC program (/clr) that is a remoting client. My issue is that once we have got our remote object, then for some wacko reasons as yet unknown to me, I am unable to create a view for a frame window. The Create just fails.
My solution to this was to create the window and hide it before the remote object was obtained and then to show/hide it as required.
But the issue is that sometimes the user can do something where the remote object is created, then he goes back to the main window, then he comes back to this window where the remote frame/view is created. Now if the GC is given enough time to destroy the unused object, everything is fine.
But my problem is that the GC is sorta slow on all this and I am having problems.
So, how do I force the GC to destroy the remote object? And what do I do if the GC fails to recognize the object as unused and thus fails to free it? Is there anyway I can simulate a delete on a managed object?
Regards,
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
