|
I'm pretty sure that all the code I've ever used in C# to grab screens used p/invoke to call native APIs. Why do you need to do it using .NET ? I mean, if you're in MC++, you've got the C++ APIs right there.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks for the reply, you may be very right about that. Mind telling me which API calls that were? I'd really appreciate this because I'm pretty tired of searching.
|
|
|
|
|
From my C# code:
[DllImport("gdi32.dll", EntryPoint = "DeleteDC")]
public static extern IntPtr DeleteDC(IntPtr hDc);
[DllImport("gdi32.dll", EntryPoint = "DeleteObject")]
public static extern IntPtr DeleteObject(IntPtr hDc);
[DllImport("gdi32.dll", EntryPoint = "BitBlt")]
public static extern bool BitBlt(IntPtr hdcDest, int xDest,
int yDest, int wDest,
int hDest, IntPtr hdcSource,
int xSrc, int ySrc, int RasterOp);
[DllImport("gdi32.dll", EntryPoint = "CreateCompatibleBitmap")]
public static extern IntPtr CreateCompatibleBitmap
(IntPtr hdc, int nWidth, int nHeight);
[DllImport("gdi32.dll", EntryPoint = "CreateCompatibleDC")]
public static extern IntPtr CreateCompatibleDC(IntPtr hdc);
[DllImport("gdi32.dll", EntryPoint = "SelectObject")]
public static extern IntPtr SelectObject(IntPtr hdc, IntPtr bmp);
I believe Nish has an article on screen capture on the site, I recommend searching for it.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Nevermind, I found out that it was pretty easy actually. Just got the HDC by using the HWND and a bit of a copy-paste. Thanks for the help!
|
|
|
|
|
Hi
Quick question, just started playing aroung with windows form applications yesterday instead of console applications (which I have strated on to practice c++) and wondered if anyone could help me out here.
I have developed 2 windows forms in my project so far. One is the 'Main Screen' and the other one is an 'Instructions' screen and am trying to use 'button' controls to link the 2 forms together, I have got my 'exit program' button working ok using the code below.
private: System::Void button1_Click_1(System::Object^ sender, System::EventArgs^ e) {
Application::Exit();
But what I need to know is what kind of code do I need to use to have the button on my 'main screen' to link me to the 'instructions screen'. Is this possible????.
Web searches are way too vague to get the info I need.
Any help would be greatly appreciated and thanks in advance to anyone who answers this.
I really hate this darn machine;
I wish that they would sell it.
It won't do what I want it to,
but only what I tell it.
~Author Unknown
|
|
|
|
|
Mark_Murphy wrote: Web searches are way too vague to get the info I need.
I guess you need some help with how to google...
Mark_Murphy wrote: button1
First of all, I recommend giving your variables meaningful names.
Create a button, create a click event for it. In the click event, create an instance of the form that shows the instructions, then call ShowDialog on that instance to show the other form.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
I am writing a program that should do the following
-Get input from the microphone attached to the pc
-Store that input in a variable
-Use that variable to control the up and down movement of a machine
The variable needs to increase as the volume from the mic increases and decrease in like manner.
Can someone give me some tip on how to do this? I do not know where to start from.. I intend to use C++
Thanks in advance... commickey
|
|
|
|
|
Do you intend to use .NET, or are you asking in the wrong forum ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
We really need to find comprehensive information on implementing .Net 2 libraries, including patterns for design time handling of visual controls, designers, editor implementations, and so forth. Does anybody have a favorite, up-to-date .Net 2.0 reference they can suggest that will satisfy just about any need for design patterns?
|
|
|
|
|
I'm looking for a good plugin system for C++/CLI that would be able to load interface elements (forms) from the plugin DLL.
I'm currently using the MFC extension DLLs that export Doc/View classes, but I unfortunately cannot use .NET controls there, due to architectural constraints.
Any suggestion, especially linking me to good reference materials, is welcome. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
You can do that using the Reflection library.
led mike
|
|
|
|
|
Thank you very much for your answer.
Do you think I could cross-use C++ and C# modules in such solution, and still get the Reflection working well?
|
|
|
|
|
Bartosz Bien wrote: cross-use C++ and C# modules
If the C++ Dll's are managed .NET assemblies then yes? Cross language compatibility is one of the features of the CLR concept.
led mike
|
|
|
|
|
hi friends
i have try making the the installer for the pocket to install the cab file from the desktop pc but it did not work
can any body help me
thanks
dzfvdsfg
|
|
|
|
|
We're moving our code bases from Delphi/CPPB to managed C++... just getting our feet wet in VS.
Delphi has what are called "Class References," which are types which represent classes. You can declare a class reference type for instance, MyClassReferenceVariableType = Class of MyClass;.
As variables of type MyClassReferenceVariableType can then be assigned the class identifier of MyClass or of any descendant of MyClass, we can pass class reference arguments to a factory method, capable of creating on the fly, any descendant or member of MyClass. Thus a singular factory method can serve purposes similar to templates, but *at run time*. C++ Builder emulates this concept with MetaClasses and __ClassIDs.
That said, is there an equivalent to such class reference types in managed C++ for .Net?
|
|
|
|
|
mmontagne wrote: That said, is there an equivalent to such class reference types in managed C++ for .Net?
I would imagine you could implement similar functionality using reflection
|
|
|
|
|
Just a while ago, an ongoing search turned up the System::Activator class, but it will be some time before I can put together a test situation, working with the other difficulties we are confronted with. If anyone else is interested, here's a link to the Activator class topic:
http://msdn2.microsoft.com/en-us/library/system.activator.aspx
I think this will work, but any further ideas appreciated, especially proven techniques.
Much thanks,
mike
|
|
|
|
|
Try this. Assuming you have a class Blah and you want to instantiate an instance of it
namespace MyNameSpace
{
public ref class Blah
{
public:
Blah()
{
}
};
}
void SomeOtherMethod()
{
//assumes class Blah has a constructor with no arguments
//note the use of c# style of specifying namespaces with . and not ::
System::String ^ className = gcnew System::String("MyNameSpace.Blah");
System::Type ^ aType = System::Type::GetType(className);
System::Reflection::ConstructorInfo ^aC = aType->GetConstructor(gcnew array<System::Type^>(0));
System::Object ^ aBlah = aC->Invoke(gcnew array<System::Object^>(0));
aBlah is now an instance of Blah but needs to be casted
}
Not sure if this is exactly what you want but its a start
|
|
|
|
|
|
After studying this, I would have serious problems with the need to cast aBlah, if this would force us (or clients) to deploy casting parameters.
Of course, as MyClass is the base class for all legal descendants to be constructed by the factory method, we could possibly eliminate our needs to cast by trying something like this with your code:
OurNameSpaces::MyClass ^ aBlah = aC->Invoke(gcnew array<system::object^>(0));
That may fix things for us, but it may convolute things for clients wanting to process their own descendants of MyClass if they are still forced to cast when our code creates instances of MyClassDescendants for them.
As it appears that your skills are quite firm (cheers), I'm curious about your assertion that there will be a need to cast when it appears your snippet coerces a call to the desired constructor. The factory method we need to translate from Delphi/CPPB generates the usual MyClass instances for clients, but allows them to declare and define their own MyClassDescendants, and, without deriving from the factory object or having to install a custom factory object descendant in the IDE, our factory object class creates and manages their needed, various descendants of MyClass for them. In fact, the factory will dynamically, alternatively create any different descendant, simply by passing the class reference parameter (this is the whole purpose of such factory methods).
Because these are the purposes, if we construct their descendants as OurNameSpaces::MyClass, we will want them not to have to cast to MyClassDescendants to perform their own processing of their MyClassDescendants instances.
We're brand new to managed C++, these libraries, and the VS compiler, but it seems that what we really want to be able to do is call either our constructor (for base class instances generated by the factory) or the client's constructor (for client descendants to be generated by the factory). That would seem to mean that we cannot eliminate *our* need to cast by the approach, OurNameSpaces::MyClass ^ aBlah = aC->Invoke(gcnew array<system::object^>(0)), because client MyClass descendant constructors may be written outside of our namespaces. I'm just thinking out loud, but it seems that the concern to accommodate the client in turn means that we would have to preserve the System::Object aspect of your approach, which would mean that both client code and our code are back to having to cast.
In the MSDN example for System::Activator (http://msdn2.microsoft.com/en-us/library/system.activator.aspx), the (VB example source) approach is a bit different:
Dim o As Object = Activator.CreateInstance(GetType(StringBuilder))
I have to build quite a library of classes before I can test either approach under real conditions, so it will be a while before we know if the latter will avoid the need to cast. But again, thanks for the starting point (which may be much more than that).
|
|
|
|
|
mmontagne wrote: if they are still forced to cast when our code creates instances of MyClassDescendants for them.
I don't understand. If you have a factory that returns a "base" class how do you access extended attributes of the derived type without casting to the derived type?
led mike
|
|
|
|
|
That's the way it works with Delphi/CPPB class references -- which is desirable for the purposes, and what I'm hoping to emulate/replicate in managed C++.
When you assign the class identifier (name) of a derived class to a class reference and pass the class reference to a factory method, it calls the constructor of the derived class and constructs an instance of the derived class which does not have to be cast. Of course, as the derived class inherits the members of the base class, it is also safe to call the methods of the base class in the derived class instances.
So this capability is exceedingly simple and clean. All you have to do is declare a class reference type, and variables/arguments of this class reference type. The class names/identifiers of the base type and all of its descendants are legal values to assign to the class reference variables or arguments. Your factory method simply takes a class reference and calls the proper constructor.
So for instance (in Delphi syntax), here is one valuable way to implement class references in a factory object:
MyBaseClassReferenceType = class of MyBaseClass; // Type/class definition (complete).
// The following is a field declared in TMyFactoryObject base class, which orients all (similar) methods to any focused FactoryCreationClass descendant:
FFactoryCreationClass: MyBaseClassReferenceType; // Member variable/field. In Delphi, instance types are declared after a colon, which is preceded by the reference (pointer) name.
// "class" methods are roughly the equivalent of static functions of C++. This one "class"/static method instance thus is shared by all TMyFactoryObject instances and descendants, but returns the desired, constructed FactoryCreationClass instance to the calling TMyFactoryObject (as intended):
class function TMyFactoryObject.CreateBaseOrAnyDescendantFactory(TMyFactoryObject: FactoryObjectInstance): MyBaseClassReferenceType; // Return types, in Delphi, are declared after the method signature.
begin
Result := FactoryObjectInstance.FFactoryCreationClass.CommonConstructorName(ArgumentsRequiredByFactoryCreationClass);
end;
This of course is powerful, fast (it's all inherently pointer based), and produces exceedingly light footprints.
So, I understand why you would ask the question, as this does not fit cleanly within the pattern of ANSI C++, because when we call the constructor of the base class name (which has a different identifer/name, versus the shared name of overridden constructors in Delphi) this will only create the parts of the base class. Here, what's happening is the constructor of the intended descendant is indeed called (which inherits the same name, "Create", of the constructor of the base). The nomenclature indicates this descendant constructor (or the base constructor, if the base class is assigned to FFactoryCreationClass). Thus, a descendant instance is returned which does not require casting.
Hmmmm... now that we think of it, probably this ambiguous identification of the necessary constructor explains the need for said Activator class, eh?
-- modified at 16:01 Friday 29th September, 2006
|
|
|
|
|
mmontagne wrote: When you assign the class identifier (name) of a derived class to a class reference and pass the class reference to a factory method, it calls the constructor of the derived class and constructs an instance of the derived class which does not have to be cast.
That sounds like you're asking for a "virtual constuctor", which does not exist in C++. The types of objects being constructed have to be known at compile time. Google for "virtual constuctor" and you'll see some ways of hand-rolling this.
|
|
|
|
|
Thanks Mike,
However, it's not really, simply a virtual constructor issue, even in Delphi or C++ Builder.
I'm aware both that we have no virtual constructors, and that we cannot call virtual methods from constructors. The nature of the constructors is not really the issue. The real issue is identifying the proper constructor of an unknown class from its class identifier. Here's the bare gist of what we need to do, expressed a bit differently:
We have a control which parents further controls of different types. Clients may populate this control with one type, with many types, and even with their own custom descendants of our base child types. Our root, composite component generates instances of these children, manages the spatial distribution and focusing of the children, routes calls to the focused child, and automates their destruction.
Clients/users may want to descend from the basic types which the original control manages; and we must also provide means for them to elect to create any one particular type (at a time) of the basic types which the control manages. This capability must be supported even at design time, in the development environment.
Because we cannot know what yet-to-exist descendants the clients of our control suite may derive from our base child classes, the necessary solution parallels our Delphi implementation, where the client can pass their class identifier (class reference) to our root control, from which our root control can identify and call the proper constructor of their descendant. Editors allow them to do this at design time, so that they do not even have to install their class/components in the IDE (which eliminates substantial work and technical difficulty for them).
The critical issue therefore is that we have to link a class identifier to the proper constructor for child classes which may not even exist at the time we produce our root component. Presently, we use a real class identifier (Delphi/CPPB "Class Reference") which is intrinsically associated with the constructor of the class; because, in Delphi/CPPB, we can call the proper constructor directly, because *it is* the default constructor of the class identifier.
But you have me thinking here. I suppose we could take a string identifier and constructor fields of a struct as our former argument, thus explicitly identifying the constructor to call -- although I don't know what issues might exist for supporting this valuable behavior at design time in VS. In other words, how would we store handles of constructors of client descendants in a collection property, so that they could be called at run time or design time?
|
|
|
|
|
PS.
All this (except how to store or manage class identifier *properties*) may be moot however, if the Activator class provides the needed services.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
