|
You have two alternatives, using COM or a C interface. Which one suits you best depends on what sort of data and parameters you have, and how complex your interface is.
Putting a C interface on your classes means that you don't export any C++ classes or functions, and use no MFC or C++ classes in your interface. This tend to require a bit more work on the side of the user of the functions. For instance, instead of creating an instance of a class and call functions on that, you would call a free function that creates one internally, and gives you a handle to it. You then use that handle in subsequent function calls (in MFC, all CWnd classes wraps a HWND handle - for this you'd do the opposite).
If you want to keep the class interactions, you have do duplicate them in COM. Keep the classes you have, but wrap them in COM class interfaces. This tends to be more work for the library writer, as you have to create and register interfaces and do marshalling and type conversions, but it will let VB, C# and Delphi to work with the COM classes rather than a C function interface.
Both methods work for VB, C# and Delphi - it's just a matter of choosing where the pain is. 
|
|
|
|
|
The interface are very simple, but are all C++ classes and i use MFC functions and classes.
I take a look to all proposed solutions.
Thanks to all very much.
|
|
|
|
|
plz post or reply through a code solving patience sort as soon as possible
|
|
|
|
|
|
link[^]
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
|
pretty please? 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Sorry, I just don't have the patience.
|
|
|
|
|
|
Is there a way to hide/show, enable/disable a "child" window with IAccessible ?
I can only get some values (::get_accState(), STATE_SYSTEM_INVISIBLE, ...) but cannot set them
It is for a "QWidget" window class, where all the childs that I enumerate (AccessibleObjectFromWindow(), AccessibleChildren()and so on) have of course no window handle (the same as the parent in fact) and I cannot use standard apis like EnableWindow() or ShowWindow()
|
|
|
|
|
Castorix wrote: It is for a "QWidget" window class
I'd imagine you'd want to search the Qt documentation for how to do this.
Castorix wrote: I cannot use standard apis like EnableWindow() or ShowWindow()
Typically these API's are built over the Windows messaging system, so even though you can't access the calls directly, you can actually still send the message to the Window. If Qt isn't intercepting or doing anything weird with those messages, they may still work (although I'm not sure if the Qt framework still uses regular Windows APIs underneath the hood to make windows when working within the Windows environment).
|
|
|
|
|
There is only one real window ("QWidget" class which allows me to use AccessibleObjectFromWindow()) but all childs are not windows, so I cannot send win32 messages.
I can enumerate them and read their properties (exactly like AccExplorer32 does), but I did not find a way to change them as I cannot interact directly with them using Win32 messages/apis
|
|
|
|
|
Castorix wrote: There is only one real window ("QWidget" class which allows me to use AccessibleObjectFromWindow()) but all childs are not windows, so I cannot send win32 messages.
Actually... this depends on the Qt implementation, they might be windows. In MFC, all childs are windows (to some extent, most are derived from the same classes), so you can message any of them.
Castorix wrote: I can enumerate them and read their properties (exactly like AccExplorer32 does), but I did not find a way to change them as I cannot interact directly with them using Win32 messages/apis
Again, this depends on Qt implementation... but you can send windows messages to ANYTHING that's a window in MS Windows. If within Qt, they simply wrapped the MS lower level APIs, then you can access those windows directly by messaging them.
By the way, not because you can do it does it mean you should.
|
|
|
|
|
No, I'm talking about a real case where there is a "QWidget" main window and NO real child windows (I can check with Spy++), so I know I cannot send win32 messages and I cannot use Win32 apis on them, because they are not Win32 windows.
I did all the code to enumerate pseudo-childs with IAccessible interface and get their properties/states
I just wanted to find a way to enable/disable one of these pseudo-windows (a pseudo-button (not a Win32 "Button" class), with no window handle)
but it seems impossible.
|
|
|
|
|
I would assume Qt has methods for all of this... have you checked out their documentation? Although from my own personal experience... I know their documentation isn't very good.
|
|
|
|
|
Our application develped in C# uses a dll and static library(lib).
The dll is intermediate project for static libraty and C# application.
Client has provided files(library file and a dll) which is required for interacting with their application.
1. In our C++ static library we are using only the library file provided by client by statically linking it.
2. Our C++ wrapper dll references this C++ static library created in step 1.
3. C# application references the wrapper dll created in step 2.
Since the library file is statically linked in our C++ static library, does the dll also need to be linked/referred in our application.
|
|
|
|
|
its not clear how the c# application (3) is using the c++ wrapper (2)
if you're using p/invoke, then the 'reference/link' is in the p/invoke statements themselves, ie, the DllImport clause
|
|
|
|
|
If the C++ dll has been linked to the static library, then you only need access to that dll in your C# code (assuming I have understood the question correctly).
|
|
|
|
|
Member 11201788 wrote: Since the library file is statically linked in our C++ static library, does the dll also need to be linked/referred in our application.
Do you mean dll or lib at this point?
If you mean lib, then it should be a no, you don't need a reference to it while building your C# application. If you mean dll, then yes, your C# application does need a reference to your dll.
|
|
|
|
|
Since the library file(lib provided by client) is statically linked in our C++ static library, does the dll(lib provided by client) also need to be linked/referred in our application.
They(client) have provided their .lib and .dll. Can we use only .lib in our C++ static library.
|
|
|
|
|
Member 11201788 wrote: Since the library file(lib provided by client) is statically linked in our C++ static library, does the dll(lib provided by client) also need to be linked/referred in our application.
Shouldn't have to... if you load the lib into your dll properly.
Member 11201788 wrote: They(client) have provided their .lib and .dll. Can we use only .lib in our C++ static library.
Again, should be able to just use the lib, since it's a collection of objects. Only thing that may be a limiter is that you have to use a lib that was compiled with the same compilation settings as your project, since the name mangling of C++ can affect you being able to find your methods. A lot of people tend to do their exports/imports in a C-style format even within C++ in order to avoid C++ name mangling issues.
|
|
|
|
|
I am expanding my knowledge of class templates so I am building a very basic template of type Array<T>.
I'll include only the code that pertains to the behavior that is confusing me.
Template Header
#include <stdexcept>
#define CORE_ARRAY_DEFAULT_LENGTH 20
template <class T>
class Array
{
private:
T** _array;
int _size;
int _length;
public:
Array(void)
{
_array = new T*[CORE_ARRAY_DEFAULT_LENGTH]();
_size = CORE_ARRAY_DEFAULT_LENGTH;
_length = 0;
}
~Array(void) { Clear(); }
int Size(void) const { return _size; }
int Length(void) const { return _length; }
T operator [] (int index) const
{
if ((index < 0) || (index >= _length))
throw std::out_of_range("index");
else
return * _array[index];
}
void Add(T value)
{
if (_length == _size)
Resize();
_array[_length] = new T(value);
++_length;
}
}
And the source
#include "MyArray.h"
#include <cstdlib>
#include <cstdio>
void main(void)
{
Array<int> iArrayA;
for (int i = 0; i < 10; ++i)
iArrayA.Add(i);
for (int i = 0; i < 10; ++i)
printf("%d\n", iArrayA[i]);
Array<int> * iArrayB = new Array<int>();
for (int i = 0; i < 10; ++i)
iArrayB->Add(i); for (int i = 0; i < 10; ++i)
printf("%d\n", iArrayB[i];
delete iArrayB;
system("pause");
}
Here is what I had to change it to to get the desired results:
printf("%d\n", iArrayB[0][i]);
What I don't get here is why when the array was declared as a local (Array<int> iArrayA;) did the accessor [] pull the stored int at the correct element but when I had the array declared as a pointer on the heap (Array<int> * iArrayB = new iArray<int>();) the accessor [] was seemingly pulling random data until I added the [0] before the [i]?
I am wondering if this has something to do with overloading the array subscript operator. Which is what has jumped out at me while I am writing this.
Also, is there a way I can code the accessor to work for both locals and heap pointers? Is there any way around this?
|
|
|
|
|
private:
T** _array;
Why is this an array of pointers to T types, rather than just an array of T types? Woudl it not be better to have something like:
T* _array;
_array = new T[CORE_ARRAY_DEFAULT_LENGTH];
T operator [] (int index) const
{
if ((index < 0) || (index >= _length))
throw std::out_of_range("index");
else
return _array[index];
}
|
|
|
|
|
For one, I've designed it to create heap copies of everything that gets added. This way it can handle both primitive data types and objects and be able to delete them. My first attempt at this used this approach but I ran into problems when trying to handle objects created on the heap. You can't delete primitives and if you don't delete heap objects, it leaks memory. By making it create all of its data on the heap no matter what get's passed in, I can avoid this problem.
Edit: I got the T** _array; idea from my practice attempts with the DirectX SDK. I saw it use this approach all over the place.
|
|
|
|
|
The reason for the different behvior is that you can only override the accessor [] for an instance or reference but not for a pointer. Using [] on a pointer is always interpreted as pointer + index by the compiler. So the compiler thinks you have an array of Array.
The usual syntax around this is
printf("%d\n", (*iArrayB)[i]);
This makes clear that iArrayB isn't an array but a pointer to a single object, and that you want to call the operator for the object it points to.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
