|
Yep - very good advice indeed.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
There was a possiability to format some "extended" properties of text with "old" GDI. It's true for comparisng of "old" RichTextBox (I mean COM-component) and ones from Windows Forms. For example, intercharacter spacing (like in Word documents), superscript and subscript. GDIplus allows only formatting of string alingment, text face and size. Using GDI handle of GDIplus Graphics object with "old style" GDI functions is seems not practical for productivity reasons. Using secondary (inmemory) device context and selfrendering text formatting for control in it is some kind of head pain too. Is where other choices?
|
|
|
|
|
I am required to submit a mail server project after approximately 2 months but the problem is that I can't decide the proper programming language that is most suitable for this project.
Please Help....
SS
|
|
|
|
|
You want to write a mail server, and you were supposed to have it done two months ago, or you have two months to do it ?
If you know C++, then I'd say C++. If you don't, then try C#. If you're saying it has to be a .NET language ( seeing as you asked here ), then C# or VB.NET can essentially do the same things, even if C# does them nicer. Both of them can probably do most of what C++ does as well, given pInvoke as an option.
The number one question is, what languages do you know well ? If you only know VB.NET, then much as it sucks, the beginning of short project is not the best time to start learning C++, or even C#.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hello, this website has helped me tremendously in my indenpendent projects I have been working on in Visualy C++ .NET 2003 IDE. Anyways, I have been working on a video game and when I copy the current directory I am on to make a new version, I get the following error: "error from resgen.exe". I looked at FAQs online and found out what resgen.exe does and so I made a fresh directory of resources, and added them to the project once again, however I still received the same error. Is there something I missed or something else I can do to get rid of this error? Thank you for all the help.
Michael L. Allen
|
|
|
|
|
Hey everyone, a quick thanks for taking a look at this...
Basically, my problem is this... I have a "Core" library which contains a "Manager" component, and I want to use this component in C#. This component is written in C++, and here is the IDL file defining its type library.
<br />
import "unknwn.idl";<br />
<br />
[<br />
object,<br />
uuid(822A2EDE-09F1-45b8-B80E-A32F21415677),<br />
helpstring("Interface used by the Manager")<br />
]<br />
<br />
interface IManager : IUnknown<br />
{<br />
HRESULT GetAppName([out, size_is(, *pcMax)] char **ppAppName,<br />
[out] long *pcMax);<br />
<br />
HRESULT SetStatus([in] long cLength,<br />
[in, size_is(cLength)] char* id,<br />
[in] int s);<br />
};<br />
<br />
[<br />
uuid(AE068C74-0B8B-4041-8CA9-4A590DDDC382),<br />
helpstring("Core Component Library")<br />
]<br />
library Core<br />
{<br />
importlib("stdole32.tlb");<br />
importlib("stdole2.tlb");<br />
<br />
interface IManager;<br />
}<br />
Now, if I write a C++ app to use this component, doing this, it works great...
(Keep in mind, the component is registered in the registry and the DLL creates an instance of the component by using IClassFactory)
<br />
#include "stdafx.h"<br />
#include <objbase.h><br />
#import "Core.tlb"<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
HRESULT hr = NULL;<br />
CLSID clsid;<br />
<br />
::CoInitialize(NULL);<br />
<br />
Core::IManager* pManager;<br />
hr = CLSIDFromProgID(OLESTR("Core.1"), &clsid);<br />
<br />
if(FAILED(hr))<br />
{<br />
cout << "DLL not installed correctly" << endl;<br />
}<br />
<br />
hr = ::CoCreateInstance(clsid, NULL, <br />
CLSCTX_ALL, __uuidof(Core::IManager), (void** )&pManager);<br />
<br />
<br />
if(SUCCEEDED(hr))<br />
{<br />
cout << "Found component!" << endl;<br />
<br />
}<br />
}<br />
No problem, it executes just fine, my C++ app easily uses the component.
Now, I try importing "Core.tlb" into .NET, by using tlbimp.exe, I get a useless managed assembly... After pouring through MSDN article after MSDN article, I've come to the conclusion that its possible to create a COM class wrapper? However, I've had no luck with that as well... This is all I've been able to come up with, but I know it doesn't work...
<br />
namespace Core<br />
{<br />
[Guid("822A2EDE-09F1-45b8-B80E-A32F21415677"),<br />
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]<br />
interface IManager<br />
{<br />
void GetAppName(<br />
[Out, MarshalAs(UnmanagedType.BStr)] string strAppname,<br />
[Out] int maxSize);<br />
<br />
void SetTestPointStatus(<br />
[In] int MaxLength,<br />
[In, MarshalAs(UnmanagedType.BStr)] string id,<br />
[In] int status);<br />
}<br />
<br />
[ComImport, Guid("AE068C74-0B8B-4041-8CA9-4A590DDDC382")]<br />
class CManager<br />
{<br />
}<br />
}<br />
Anyone have any suggestions? I've come to the conclusion that I really have no idea what I'm doing in C# as far as interop goes, I'm not a bad C# coder, but this just escapes me at the moment...
Anyway, thanks again for reading this 
|
|
|
|
|
If you add a reference to your com object ( right click on references in the solution pane, click add reference, the COM tab and scroll down to your object ), your object will become available through a new namespace, which will be the name of the object, visible in that list of references.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
First, thank you very much for your advice...
Hmmm, I've tried that, but like I said, I don't really have that usable of an interop assembly... It only gives me Core::IManager, just the interface... Do I have to implement that interface, or write a wrapper for that? There are no class objects for me to instantiate... Some sites talk about coclasses, but I have none defined in my IDL file, and I'm not really sure what I'm doing as far as that... haha, am I just doing this wrong?
Thanks again
|
|
|
|
|
My code just does this:
AVIFileInProc avi = new AVIFileInProcClass();
The trick was working out on which side the name with 'Class' in it went. I just imported the COM object, and put 'using typename;' at the top of the class where I use it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hmm, I tried that, but it can't find any IManagerClass class... I know that when you use tlbimp or import a DLL or type library through .NETs Add Reference thing, in the managed assembly there should be 2 public classes;
IManager
IManagerClass
but only IManager is there when I run the MSIL Disassembler...
Maybe my IDL file is wrong? Or should I just give up with trying to import the type library and figure out the hard way how to write a COM class wrapper?
Thanks again
|
|
|
|
|
I imagine that the class is hidden behind a namespace and you need to work out what the namespace is. It's the same as the type name you'd use to spin a COM object in VBScript.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Please try tlbimp on the dll and see what error you are getting.
tlbimp 'dllname'
|
|
|
|
|
We have a project that was just converted form 6.0 to .NET, which, in turn, generated a ton of errors. Most of them we're getting worked out, but this one seems to be really stubborn. It doesn't happen in all of the projects, just some of them; we can't seem to figure out why. Unfortunately, we're all relatively new to the .NET enviroment, so we're learning as we go.
The include statements have the correct syntax: #include "somefile.h" and some of the .h files are in the project (although others are not). We did try including the .h files into the whatever project was generating this error, but it didn't help.
We've checked the enviroment variables and they're fine; exactly what they should be. We know that we can include the entire path to correct this, but there are hundreds of files in dozens of projects that may need to be changed; we're trying to find an easier way to correct this error.
Any ideas?
|
|
|
|
|
Found the problem. Working fine now.
|
|
|
|
|
Hi guys :->
Anyone knows how we create a standalone manifest file? A file which only contains metadata not any IL code.
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
|
Hi,
I am working on a Windows based C# application, running on XP on Framework 1.1. The main UI of my application contains a Tab Control, and on a particular action (such as a button click) a module is opened in a Tab Page in the Tab Control.
My question relates the following strange observation: When I execute my application (in Debug mode) and check for the memory status in Task Manager, I notice that every time I open a module, a large amount of memory (about 20 MB) is created. But when I close the module only a small amount of memory (about 2 MB) is released. I have checked in two different Memory Profilers to ensure that all the objects are garbage collected properly; both the profilers report complete release of managed memory. One of the profiler actually reports only 2MB as allocated on the managed heap when my module is opened and the same amount as reclaimed when closed.
When I perform the above operation of opening and closing of the module contineously, Task manager shows that each time there is an increase of about 1 MB in memory size.
I am using a COM object, which is being released with the call Marshal.ReleaseComObject(). I also use a Win API call from a "static extern" declaration.
Any idea why this could be happening?
Thanks in advance.
Regards,
Edwin.
|
|
|
|
|
Edwin Anand wrote:
and check for the memory status in Task Manager
First, do not ever do this with Task Manager. It will never give you how much memory your managed .NET application is actually using. Use Performance Monitor and the .NET Framework counters to do this.
Here's the simplified explanation:
What you're seeing in Task Manager is how much memory has been reserved for your applications MANAGED memory heap, not how much your app is using! The Managed Heap is a nice size block of memory, reserved for your applications use, created out a block of unmanaged memory. There's a reason why the .NET Framework runtime environment is called a virtual machine, just like Java's runtime environment.
The .NET Framework memory manager will set aside a block of unmanaged memory (what you're seeing in Task Manager) and create the Managed memory heaps in it. When you application creates an object, it's created in either the Small Object Heap or the Large Object Heap, depending on the objects initial size. Since this object has been created inside the Managed Heap, there's no effect on what you see in Task Manager since it only looks at unmanaged memory. When the object goes out of scope, the memory gets released back to the Managed Heap, not the unmanaged.
Now, the numbers you see in Task Manager DO change during your applications execution. Why? There's a couple of reasons.
The .NET Memory Manager likes to keep a cushion so the next time you allocate an object, you don't have to wait for the memory manager to grab another block of unmanaged memory and add it to the managed heap, then allocate your object in it.
But, the memory manager also has to balance what it allocates against what Windows wants for other buffers and processes. The memory manager, when it thinks there is too much unmanaged memory allocated to your app, will release managed memory back to the unmanaged heaps. This will happen when you deallocate an object or when your applications data gets swapped to disk and back to RAM.
To see a little demo of this, try starting your application and watch what happens in Task Manager. You'll start out with a good size chunk of memory (roughly 15-20 Meg on startup). Now minimize your application and watch what happens in Task Manager. It drops considerably because your app just got swapped to disk. Restore your app so you can see it again and your app's memory consumption will increase, but not as high as when you started your app. Since your application didn't need some data and free space, the memory was either not swapped back to RAM or was released back to the unmanaged pool.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi Dave,
It seems that you know a lot about memory stuff (Oh yeah you're so smart  ).
I use Process Explorer instead of the Task Manager.
And i see 3 columns: Working Set, Virtual Size and Private Bytes.
Do you know what these memory-items mean?
I think Private Bytes is the Managed Heap you're talking about, but i'm not really sure.
And do you know which of the three is important to keep as low as possible?
Thank you! 
|
|
|
|
|
Working set is the number of pages of that process that are currently in physical memory. I'm not sure about virtual size, private bytes is the number of bytes that can't be shared with other processes. Typically, code can be shared with other processes, but because .NET using JIT compilation, private bytes tend to be on the higher side for .NET apps.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Ok, thank you!
Now i understand it a lot better!
I guess i've to keep Working Set & Private Bytes as low as possible...
Thanks Again!
PS: Does anyone else knows what Virtual Size means 
|
|
|
|
|
Thank you Dave. That was very useful information!
-Edwin.
|
|
|
|
|
Hey guys,
I've got a VS.NET setup-project that I recently made for a VB.NET program that I wrote. The program requires some 3rd party files that another setup installs. I use a custom action to launch the third party setup. Here is my problem: After the 3rd party setup finishes, it asks the user if s/he would like to restart their computer now or later. If the user decides to restart immediately, the shortcuts and menu links of the main program never get installed because the restart stops the original setup.
Is there any way to launch the 3rd party setup after my setup? Or does anyone have any other ideas?
-Waffleman
================================
Freiheit ist von Gott, Freiheiten vom Teufel.
|
|
|
|
|
Dear Waffleman,
Option 1:
Try using Process.Execute(...) from your Custom Action in order to execute the third party installation, if it does not violate your installation sequence.
Option 2:
Get into the msi database by using some free tools such as Orka (from microsoft). Please search for it in msdn for more info.
tth.
-Edwin.
|
|
|
|
|
The fact that you can even launch the setup from a VS.NET setup means that it was not created using Windows Installer, because Windows Installer does not allow a second instance of msiexec to be launched.
This precludes the option to edit the 3rd party setup with Orca.
You still have a couple of other possibilities:
1) Determine what was used to create the 3rd party install (ex. Wise, Installshield, etc) and see if the 3rd party setup supports execution with a commandline switch that suppresses the reboot option. Many setups support this feature, but not all. If your setup supports a switch to suppress the reboot, you simply modify your custom action commandline.
This option presents a certain problem however. A lot of setups are authored to automatically offer a reboot option, even though a reboot may not be required for the software to run. In other cases, a reboot may be required only on certain OS versions or only if certain files were in use. It is pretty much impossible to know (or test under all possible scenarios) if the reboot is actually required or if it was merely authored into the package.
So basically you are left iun a situation where the only assumption you can make is that the reboot is required, but you have now suppressed this option, and the user may try to use the software and think the setup failed. So you should probably author your MSI to force a reboot to be safe. This is not something you can do in the VS IDE so you will have to download Orca and the Windows Installer SDK and figure out how to modify your VS.NET setup to force a reboot at the end.
This is not a trivial task, unfortunately.
2) A second option, which in my opinion is probably easier, but requires you to be able to at least manage some level of C++ programming, is to modify the bootstrapper EXE.
VS.NET includes a standard bootstrapper called setup.exe. This is a program that usually first checks to see if the Net framework is installed. If so it launches your msi and terminates. If not, it first runs the dotnetfx.exe to install the Net Farmework, then launches your msi and terminates.
You can download the bootstrapper exe source code from the MSDN site, and modify it to do anything you want.
In this case you would want to modify the bootstrapper to launch your msi, but NOT terminate, wait for a successful return code from the msi install, and then launch your 3rd party install and terminate. This will result in your 3rd party install being the last operation required in your setup sequence, and you can allow the user to reboot because all other setups will have already completed.
I suggest you try the second option if you can manage the C++ code. It's not particularly difficult, if you have at least some very basic experience with C++, or even just a good reference text.
Robert
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
