|
|
It is a shame that this is not part of the framework and you have to result to using an old API call for it.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
Ray Cassick wrote:
It is a shame that this is not part of the framework and you have to result to using an old API call for it.
I suppose all we can do is hope for nice updates to the Framework as it ages, I wonder what other functions people are missing from the .NET Framework. I think this might be a survey question in the making.
Nick Parker
You see the Standards change. - Fellow co-worker
|
|
|
|
|
My guess as that once the OS itself becomes more .NET centered this will also change.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
|
Nick Parker wrote:
I wonder what other functions people are missing from the .NET Framework
The Profile (INI files) functionality from the Win API... how simple and yet annoyingly absent.
Paul
Pleasently caving in, I come undone - Queens of the Stone Age, No One Knows
|
|
|
|
|
Take a look at the System.Configuration namespace. INI file support isn't included because Microsoft is trying to get away from them and into XML. XML is extremely handy for something like this.
I don't know whether it's just the light but I swear the database server gives me dirty looks everytime I wander past.
-Chris Maunder
Microsoft has reinvented the wheel, this time they made it round.
-Peterchen on VS.NET
|
|
|
|
|
David Stone wrote:
XML is extremely handy for something like this
Sure it is, and so is the registry; I'd use both in their place.
But sometimes (usually for legacy reasons or maybe because a user who might want to hand-configure their software is [rightly] scared of the registry and sees XML as too complicated) an INI file is a nice simple answer.
MS have been saying in MSDN for years that Profile API functions are included for compatibility with Win 3.X and yet people still use them. I've seen several questions around the internet (I think mostly here) about reading INI files in C#.
Paul
Pleasently caving in, I come undone - Queens of the Stone Age, No One Knows
|
|
|
|
|
Paul Riley wrote:
MS have been saying in MSDN for years that Profile API functions are included for compatibility with Win 3.X and yet people still use them.
Well there you go. Now, since it's a lot harder, people won't use them . And for those poor fools who really need them, there's always DllImport .
-Domenic Denicola- [CPUA 0x1337]
“I was born human. But this was an accident of fate—a condition merely of time and place. I believe it's something we have the power to change…”
|
|
|
|
|
It looks like DirectShow 9 lacks support for managed code. I've seen people talking about creating COM wrappers and interop to support this.
I have glances at the DirectX.NET articles here at CodeProject, but it doesn't cover what I am mainly interested in: DirectShow Editing Services (DES). The Dexter library also lacks this.
I guess some of you have already created this stuff, so my question is: Where can I find this kind of libraries?
-Øyvind
|
|
|
|
|
In the past, I have been working with DirectShow, and from what I know :
- DirectShow Editing services is available since DirectX 8.1. May be release 9 adds a few interfaces, but that's not a requirement.
- DirectX objects are COM objects, and embed a tlb. For instance, DirectShow's type-library is embedded in quartz.dll. Who prevents you from calling this "tlbimp.exe quartz.dll" to get the interop library ? I don't know why you should install DirectX 9 just for that purpose.
Of course, once you have that interop type library, you need to rewrite the samples from C++ to C# or other .NET languages. That's probably what DirectX9 provides you for free (but again, nothing really required).
|
|
|
|
|
.S.Rod. wrote:
DirectX objects are COM objects, and embed a tlb. For instance, DirectShow's type-library is embedded in quartz.dll. Who prevents you from calling this "tlbimp.exe quartz.dll" to get the interop library?
Of course you can. What I meant was that I was hoping that DirectShow 9 would fully be supported with managed code. But it didn't.
I don't think that the DirectShow Editing Services is covered in quartz.dll. Am I right?
I guess someone already has converted the DirectShow Editing Services interfaces from IDL to C#. Where can I find this?
As you may guess I am interested in all information I can get in how to use DirectShow Editing Services from C#.
Thanks for any help.
-Øyvind
|
|
|
|
|
|
Why don't one of our experts here write an article to give us a comparison between all databases and tell us the advantages and disadvantages of every one for personal any corporate applications. I have not found such article or research anywhere.
Databases to Study:
MS Access
SQL Server
Desktop SQL Server with MSDE
Sybase Anywhere
mySQL
Oracle
SAP DB
Jassim Rahma
|
|
|
|
|
You might try this link.
http://www-3.ibm.com/software/data/pubs/pdfs/bloor.pdf[^]
I'm not suggesting it isn't biased (lets face it, a database vendor paid for it), but it does have a wide variety of information in it. At 150 odd pages, its a hefty read. (Perhaps this is why no-one takes up the challenge - a comparison of databases is not a trivial thing).
-Adrian
|
|
|
|
|
I write one dll called graphicobject.dllto Serialize store my Graphics object in order to reuse these object.
After I modified the graphicobject.dll code and complie it.
All the data I used the previous graphicobject.dll to Serialize can not open
again.
How can I do to make the previous Serialized data(used the previous graphicobject.dll) can be De-Serialize in new graphicobject.dll?
Thanks!
|
|
|
|
|
This is one of the things that I really hate about serialization. If you change the structure of the stored object you cannot use the new library to open the old file. I usually include backwards compatibility in my programs. And add version upgrade utilities, features.
If you need to get the data salvaged you will need to use the old version of the library.
|
|
|
|
|
Hello everyone,
I need to call a C++ .NET project from a C# project. Is it possible and if yes, how to go about doing it? Your help will be greatly appreciated.
Thanks alot!
min
|
|
|
|
|
What do you mean by calling C++ NET project?
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
I am using the Visual .NET studio to do the system .. I got this C++ project and C# project in the visual studio. I need to call the classes written in the c++ project from the C# project.
thanks
min
|
|
|
|
|
shimin wrote:
I need to call the classes written in the c++ project from the C# project.
Another chance for me to push my latest article (this actually does what you are asking):
Cross Language Web Service Implementation[^]
Nick Parker
You see the Standards change. - Fellow co-worker
|
|
|
|
|
I try looking thru your article but i don really understand. I am sorry, but I am just a beginner, i hope you can enlightened me.. Thanks
min
|
|
|
|
|
Is your C++ project written in MC++ or pure C++? If in MC++, then you do not have any problem, just compile the MC++ project into assembly and use it like any other .NET dll.
Make sure your MC++ classes are marked as "public _gc..."
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
the C++ is visual C++ , can i still do what you say?
and how to compilt the project into an assembly?
thanks alot for your help
min
|
|
|
|
|
You will have to study the .NET system a bit more. Visual C++ supports the normal C++ and the Managed Extensions to C++ (MC++). The MC++ is designed for .NET programming and the normal C++ for other systems.
You cannot call the normal C++ from C# or VB.NET. But you can call MC++ classes from C# or VB.NET.
Again, the question is which are you using C++ or MC++?
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|