i have to admit that i have really strange issue, which im not able to solve by my self. Im trying from few days without success.
My goal is to use Direct3DEx interfaces from C (not C++). I cant use Direct3D because i have to deal with shared resource handles with surfaces from different d3ddevices.
I have no any problems with creating IDirect3DEx from C++, works perfectly. For example this code works as expected
IDirect3D9Ex* m_d3d;
Direct3DCreate9Ex(D3D_SDK_VERSION, &m_d3d);
UINT c = m_d3d->GetAdapterCount();
m_d3d->Release();
Now im trying to do exactly the same from C,
my code is:
void *pd3dll = (void *) LoadLibrary("d3d9.dll");
UINT count;
IDirect3D9Ex *pDirect3D9ExInterface;
HRESULT hr;
typedef HRESULT (WINAPI *Direct3DCreate9Ex_t)(UINT SDKVersion, IDirect3D9Ex **ppD3D);
Direct3DCreate9Ex_t Direct3DCreate9ExFunc;
Direct3DCreate9ExFunc = (Direct3DCreate9Ex_t) GetProcAddress((HMODULE) pd3dll, "Direct3DCreate9Ex");
hr = Direct3DCreate9ExFunc(D3D_SDK_VERSION, &pDirect3D9ExInterface);
if (SUCCEEDED(hr))
{
count = IDirect3D9Ex_GetAdapterCount(pDirect3D9ExInterface); //crash
IDirect3D9Ex_Release(pDirect3D9ExInterface);
}
i dont see absolutly any reason why this piece of code doesnt work.
Please notice that code line:
hr = Direct3DCreate9ExFunc(D3D_SDK_VERSION, &pDirect3D9ExInterface);
returns S_OK, and when im checking pDirect3D9ExInterface pointer under debuger it looks like a valid pointer.
But this line of code:
count = IDirect3D9Ex_GetAdapterCount(pDirect3D9ExInterface); //crash
causes my program to crash. When im switching my DirectX9 to debug mode, on VS output window i see after crash, something like this:
Direct3D9: (ERROR) :Invalid initialization function specified. RegisterSoftwareDevice fails.
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
Additionaly if i change this C code to Direct3D initialization (no Direct3DEx) than works without any problems.
What im doing wrong? Where is the catch?
thanks in advance
Jakub
This seems to be due to a bug in the definition of the d3d9.h header file.
A function seems to be left out of the IDirect3D9Ex interface that appears in the IDirect3D9 interface (IDirect3D9Ex inherits from IDirect3D9).
In c++ this still works because of inheritance and virtual functions working correctly, in c, it doesn't correctly pick up the inheritance due to the way their v-tables are constructed.
Below I've commented out the line that needs to be added to fix this issue (in d3d9.h at line 2044):
DECLARE_INTERFACE_(IDirect3D9Ex, IDirect3D9)
{
/*** IUnknown methods ***/
STDMETHOD(QueryInterface)(THIS_ REFIID riid, void** ppvObj) PURE;
STDMETHOD_(ULONG,AddRef)(THIS) PURE;
STDMETHOD_(ULONG,Release)(THIS) PURE;
/*** IDirect3D9 methods ***/
//Add this here: STDMETHOD(RegisterSoftwareDevice)(THIS_ void* pInitializeFunction) PURE;
STDMETHOD_(UINT, GetAdapterCount)(THIS) PURE;
STDMETHOD(GetAdapterIdentifier)(THIS_ UINT Adapter,DWORD Flags,D3DADAPTER_IDENTIFIER9* pIdentifier) PURE;
STDMETHOD_(UINT, GetAdapterModeCount)(THIS_ UINT Adapter,D3DFORMAT Format) PURE;
STDMETHOD(EnumAdapterModes)(THIS_ UINT Adapter,D3DFORMAT Format,UINT Mode,D3DDISPLAYMODE* pMode) PURE;
You can double check that the functions line up correctly with the returned interface by loading the d3d9.dll symbols from the MS servers and comparing the names in the v-table with the values reported. In the image below, the left hand side is the v-table before being fixed, and the right hand side is the v-table after being fixed.
To get the symbol's from the MS symbol servers:
start the application and place a breakpoint after LoadLibrary("d3d9.dll") has been called
open up the 'Modules' window (from the menu bar Debug->Windows->Modules)
Find d3d9.dll in the modules list (try typing d3d9.dll to quickly go to it)
Right-click on d3d9.dll and click on Load Symbols From->Microsoft Symbol Servers
Wait a few seconds for it to download and load the symbols, addresses should then resolve to useful names.
Related
The problem
I am following a guide from the Microsoft Documentation and the examples there are given in C++. I could've just used the default samples in C++, but I wanted to further understand how the API works so I decided to rewrite the default C++ sample in C.
The problem I encountered is that I can easily call D2D1CreateFactory and create an ID2D1Factory, though when I was previously reading the documentation, it was stated that you have to always release the COM object after you've used it and don't need it anymore. The fact is that in C++ there's an inherited method Release from IUnknown. In C though there's no even a lpVtbl, which as far as I understand is usually needed for that purpose. The ID2D1Factory is just provided as a typedef and is an incomplete type.
And now I'm stuck, because I don't know how to release pointer. I've spent a couple of hours searching for ways to do that in C.
Is it even possible?
The header file: d2d1.h
The Code
Window Procedure simplified:
switch (uMessage)
{
case WM_CREATE:
{
HRESULT hResult = D2D1CreateFactory(D2D1_FACTORY_TYPE_SINGLE_THREADED, &IID_ID2D1Factory, NULL, &pFactory);
if (FAILED(hResult))
{
return -1;
}
return 0;
}
...
}
Obviously pFactory is of an ID2D1Factory* type in global scope. It is zero-initialized by default (if that helps).
I have a SWIG generated R wrapper which contains the following setClass operations:
setClass('_p_f_p_struct_parameters_p_struct_chromosome_p_struct_dataSet__double',
prototype = list(parameterTypes = c('_p_parameters', '_p_chromosome', '_p_dataSet'),
returnType = '_p_f_p_struct_parameters_p_struct_chromosome_p_struct_dataSet__double'),
contains = 'CRoutinePointer')
setClass('_p_f_p_struct_parameters_p_p_struct_chromosome_p_p_struct_chromosome_int_int__void',
prototype = list(parameterTypes = c('_p_parameters', '_p_p_chromosome', '_p_p_chromosome', '_int', '_int'),
returnType = '_p_f_p_struct_parameters_p_p_struct_chromosome_p_p_struct_chromosome_int_int__void'),
contains = 'CRoutinePointer')
These operation do not appear to be behaving as expected. When I call a function with the output being the creation of a _p_parameters object (defined above), I get the following error:
Error in getClass(Class, where = topenv(parent.frame())) :
“_p_parameters” is not a defined class
The setClass therefore seems to be not doing it's thing.
I tried to manually set the _p_parameters class via:
p_parameters<-setClass(Class="_p_parameters", representation = representation(ref = "externalptr"))
But this does not seem to work as when I try and modify other parameters (or even print parameters via an inbuilt function) the terminal crashes and hangs.
For reference, the final lines in initialiseParameters (the function which initially own _p_parameters) are calling the native C function via .Call then assigning the external pointer to a new object of class _p_paramters as follows:
;ans = .Call('R_swig_initialiseParameters', numInputs, numNodes, numOutputs, arity, as.logical(.copy), PACKAGE='cgp');
ans <- new("_p_parameters", ref=ans) ;
I've read various R doc on new(), setClass, S3/S4 classes but nothing seems to clarify what I'm meant to be doing here.
Any suggestions on where to start or tutorials that would give a good heads up would be most welcome.
Please keep in mind the C code is not mine (but is freely available under GNU), I am not a C programmer and am only weakly-moderately proficient in R. So please be gentle :)
Cheers.
PS: If I call the function in R terminal via .Call it works as expected (so it doesn't seem to e a C function error)
I thought I should post the solution I have to this. The least I could do for a 'tumbleweed' medal haha.
The only solution I could find to this is to comment out the following line:
ans <- new("_p_parameters", ref=ans) ;
in all function that try to create an R object.
The resulting memory pointer is then assigned to an R object at function call.
It's dirty, but I couldn't work out how to create an object from a memory pointer (at least from within the functions themselves).
It seems to work so I guess it will do.
Context
After writing a simple application using a GtkEntry widget to process textual commands from user I would like to do some design changes.
As of now I use signal hook on key-press. If key(s) are a specified value, then show command line and process various actions on entry widget. Like e.g.
Ctrl+a: move cursor to start of input.
Ctrl+u: delete text before the cursor.
...
As well as parsing commands and saving/loading history.
I am not satisfied with how this is stitched together. The command parsing becomes a subset of:
main_window -> mode_check -> command_line_act -> parse_cmd+execute
As I see it one good approach would be to write a new widget using GtkEntry as base – and send signals on command enter. All of the internals like Ctrl+... and history handled by the new widget.
Signals emitted from new widget being e.g.:
"cmdline-abort"
"cmdline-cmd"
...
Status
Have written the base for this but I am at a hault when it comes to emitting signals with more then one argument.
I have:
gtk_signal_emit(obj, sig, 0, command)
|
+---- string.
but would like, (for now at least, most likely more/other down the line.):
gtk_signal_emit(obj, sig, 0, command, length)
gtk_emit_signal Typo fixed. Thanks to jku.. Also, now using g_signal_
In widget code:
static void
cmdline_class_init(CmdlineClass *klass)
{
With one argument I am using g_signal_new() as:
cmdline_signals[CMDLINE_CMD] = g_signal_new(
"cmdline-cmd",
G_TYPE_FROM_CLASS(klass),
G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION,
G_STRUCT_OFFSET(CmdlineClass, cmdline),
NULL,
NULL,
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE,
1,
G_TYPE_STRING
);
And as I see it, for two arguments, should change it to something like:
cmdline_signals[CMDLINE_CMD] = g_signal_new(
"cmdline-cmd",
G_TYPE_FROM_CLASS(klass),
G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION,
G_STRUCT_OFFSET(CmdlineClass, cmdline),
NULL,
NULL,
g_cclosure_user_marshal_VOID__STRING_INT,
G_TYPE_NONE,
2,
G_TYPE_STRING,
G_TYPE_INT
);
Trouble in the garden
Using glib-genmarshal to generate marshals with marshal.list holding:
VOID:STRING,INT
This works, but gives me a warning upon compile time as:
warning: ISO C forbids conversion of object pointer to function pointer type
Caused by this code generated by glib-genmarshal:
typedef void (*GMarshalFunc_VOID__STRING_INT) (gpointer data1,
gpointer arg_1,
gint arg_2,
gpointer data2);
register GMarshalFunc_VOID__STRING_INT callback;
/* GCC Warnig: conversion of object pointer to function => */
callback = (GMarshalFunc_VOID__STRING_INT) (
marshal_data ?
marshal_data :
cc->callback
);
Question
Is this the wrong approach? Is there some way to fix the conversion error? Etc.
As a note: I am fairly new to Gtk, and Gui programming in general.
Side point
There are some deprecations I also wonder if could affect the code / should be avoided:
GtkSignalMarshaller, does this indicate anything about the status of GSignalCMarshaller?
GtkCallbackMarshal, does this indicate anything about the use of marshalers in general?
This warning does appear (with -pedantic) on some signal marshalling code, and not just in your code. As far as I can see you are not doing anything wrong though -- except for using gtk_signal_emit() (I assume you meant that and not gtk_emit_signal() which does not exist as far as I know): you should not use any gtk_signal-prefixed code: that stuff is all deprecated. See the reference for details. Use GObject instead: g_signal_emit() or g_signal_emit_by_name() should work for you.
The signal marshaller deprecations you mention are about this same thing: GObject handles everything related to this now (and has for a long time already).
As practical advice: Often adding things to signal signatures is not worth the trouble, and this might be the case for you as well: maybe your signal does not need the command string at all, and the signal handler could just query it with your_object_get_command()?
Practical advice #2: Consider using GTK+ 3 for new code. Not having all that deprecated stuff around confusing everyone is just lovely.
INT GetTree (HWND hWnd, HTREEITEM hItem, HKEY *pRoot, TCHAR *pszKey,
INT nMax) {
TV_ITEM tvi;
TCHAR szName[256];
HTREEITEM hParent;
HWND hwndTV = GetDlgItem (hWnd, ID_TREEV);
memset (&tvi, 0, sizeof (tvi));
hParent = TreeView_GetParent (hwndTV, hItem);
if (hParent) {
// Get the parent of the parent of the...
GetTree (hWnd, hParent, pRoot, pszKey, nMax);
// Get the name of the item.
tvi.mask = TVIF_TEXT;
tvi.hItem = hItem;
tvi.pszText = szName;
tvi.cchTextMax = dim(szName);
TreeView_GetItem (hwndTV, &tvi); //send the TVM_GETITEM message?
lstrcat (pszKey, TEXT ("\\"));
lstrcat (pszKey, szName);
} else {
*pszKey = TEXT ('\0');
szName[0] = TEXT ('\0');
// Get the name of the item.
tvi.mask = TVIF_TEXT | TVIF_PARAM;
tvi.hItem = hItem;
tvi.pszText = szName;
tvi.cchTextMax = dim(szName);
if (TreeView_GetItem (hwndTV, &tvi))
//*pRoot = (HTREEITEM)tvi.lParam; //original
hItem = (HTREEITEM)tvi.lParam;
else {
INT rc = GetLastError();
}
}
return 0;
}
The block of code that begins with the comment "Get the name of the item" does not make sense to me. If you are getting the listview item why does the code set the parameters of the item being retrieved? If you already had the values there would be no need to retrieve them.
Secondly near the comment "original" is the original line of code which will compile with a warning under embedded visual c++ 4.0, but if you copy the exact same code into visual studio 2008 it will not compile. Since I did not write any of this code, and am trying to learn, is it possible the original author made a mistake on this line? The *pRoot should point to HKEY type yet he is casting to an HTREEITEM type which should never work since the data types don't match?
The block of code that begins with the comment "Get the name of the item" does not make sense to me. If you are getting the listview item why does the code set the parameters of the item being retrieved, because if you already had the values there would be no need to retrieve them.
After that comment, the first line is to specify to TreeView_GetItem (which, by the way, is actually a SendMessage in disguise) that we want to retrieve the text of the item and the associated lParam. The next line specifies the handle to the item about which we want information.
The following line specifies where the retrieved text must be saved, i.e. in the szName buffer, which has been allocated at the beginning of the function; the last line before the function call specifies the size of such buffer, so to avoid buffer overflows.
I suggest you to have a look at the documentation of TreeView_GetItem and of TVITEM to understand better what's going on.
Secondly near the comment "original" is the original line of code which will compile with a varning under embedded visual c++, but if you copy the exact same code into visual studio 2008 it will not compile. Since I did not write any of this code and am trying to learn is it possible the original author made a mistake on this line, since the *pRoot should point to and HKEY type yet he is casting to an HTREEITEM type which should never work since the data types don't match?
It's not clear what the code is trying to do there; at first glance I'd say that in the lParam associated to each item in the root node of the treeview is stored a handle to a registry key, and the procedure retrieves it in that way. Still, if it was like that, the (HTREEITEM) cast wouldn't make sense at all; probably it was a mistake, forgiven by the compiler because it treated all handles as plain void *; if my hypothesis is correct you should keep the original line, just replacing (HTREEITEM) with (HKEY).
Many times, API calls take in information in a structure, and also return information in the same structure. If you look at the documentation for TreeView_GetItem, it will clearly show how it operates.
As for the second question, are you compiling as C++? What is the error?
The LPTVITEM parameter to the TreeView_GetItem macro is used bi-directionally.
TreeView_GetItem does indeed send the TVM_GETITEM message to the treeview. What's going on here is that the caller fills in a little bit of the struct to say "here's what I have and what I want" and then the treeview will fill in the requested bits.
From the TreeView_GetItem documentation
When the TVM_GETITEM message is sent, the hItem member of the TVITEM or TVITEMEX structure identifies the item to retrieve information about, and the mask member specifies the attributes to retrieve.
For the second part, I think it looks like it was a mistake, based on the names of the variables etc., but you should probably check how the function is used in the rest of the code to make sure.
The first question is pretty simple: you're filling in a few of the items in the structure to tell what data you want, then calling TreeView_GetItem to actually retrieve the specified data. In this case, you're specifying TVIF_TEXT, which says you want the text for the particular item. You also give it a buffer where it's going to put the text (szName), and tell it how long that buffer is (so it won't write past the end of the buffer). When you call TreeView_GetIem, it copies the text for that item into your buffer.
As to your second question: it looks like all that code (both old and new) is somewhat problematic. The general intent seems to be to retrieve the path to the item that was originally passed in, but it seems to do that rather poorly. It starts by recursively walking up the tree to the root. Then it retrieves the text for the root item, but only into the local variable szName -- which it then ignores (does not copy into szKey). It does store the handle to the root item into hItem (this is where it originally wrote to pRoot).
Then, as it returns (walking back "down" the tree), it retrieves the text for each item, and appends those names to szKey (separated by '\'), to form (most of) the path to the item originally passed in. Unfortunately, as it does this, it ignores the nMax that was passed in, so it can (apparently) write past the end of the szKey buffer.
I am struggling to implement an HID control with a Mac : I cannot send the expected function as depicted here below:
IOHIDManagerRegisterDeviceMatchingCallback( gIOHIDManagerRef, Handle_DeviceMatchingCallback, NULL );
with : gIOHIDManagerRef -> the valid HID manager dedicated to this routine
Handle_DeviceMatchingCallback --> the routine that will be called back when the HID
device is attached to the USB port
NUUL --> not used here, contain data from the USB
The issue is that Handle_DeviceMatchingCallback must be a pointer to the routine, but how can I send a pointer ?
On the other hand, all the examples , from the Apple source, are based on C, not on cocoa.
Well, does that means that I must rework my program in C ??? Or is it possible to have fraction of the program in C under the cocoa environment?
Sorry for so "stupid" question queries, but, although I have some background in the field of electronic an programming, I am very newbees with cocoa.
Your comments will be very appreciated !
Michael
Objective-C is mostly a super-set of C. In order to combine C and Objective-C code, you simply compile your C code as if it were Objective-C code. The easiest way to do this in Xcode is to ensure the file in question has a .m extension.
To route handling back to the Objective-C world, you need a pointer to an Obj-C object. Many callback-based APIs allow you to provide a generic pointer (void *) that they then pass back to you when they callback. This argument has several common names:
context or ctx
refcon (for "reference constant")
userData
userInfo
If the callback API does not allow this, you'll need some uglier way to dispatch the callback to your object, such as a global pointer or a lookup table.
The API you're using does let you provide a context pointer. When it calls back to your code, it provides you with the pointer you used when you registered for the callback. Here is an example of registering the callback from an object of type MyObjCClass (see the -registerMatching method below) and then using the context pointer to route the callback back to the object that registered the callback for handling (see the Handle_DeviceMatchingCallback function's use of the context pointer).
/*! #file C-ObjC-Callbacks.m
* Demonstrates routing a C callback to an Obj-C object
* using the callback's context pointer.
*/
#import <Cocoa/Cocoa.h>
#import <IOKit/hid/IOHIDManager.h>
// Global HID manager reference.
IOHIDManagerRef gIOHIDManager;
// HID callback
void Handle_DeviceMatchingCallback(void *context,
IOReturn result,
void *sender,
IOHIDDeviceRef device);
#interface MyObjCClass : NSObject {
}
- (void)registerMatching;
- (void)handleMatchingDevice:(IOHIDDeviceRef)device
sender:(void *)sender
result:(IOReturn)result;
#end
#implementation MyObjCClass
- (void)registerMatching {
// Assume gIOHIDManager has already been created.
// Set up a device matching callback, providing a pointer to |self| as the context.
IOHIDManagerRegisterDeviceMatchingCallback(gIOHIDManager,
Handle_DeviceMatchingCallback,
(void *)self);
}
- (void)handleMatchingDevice:(IOHIDDeviceRef)device
sender:(void *)sender
result:(IOReturn)result {
// Do something...
}
#end
void
Handle_DeviceMatchingCallback(void *context,
IOReturn result,
void *sender,
IOHIDDeviceRef device); {
MyObjCClass *const myObject = (MyObjCClass *const)context;
[myObject handleMatchingDevice:device sender:sender result:result];
}
Handle_DeviceMatchingCallback must be a pointer to the routine, but how
can I send a pointer ?
If you want to pass in a function functionName, you can pass it as
&functionName.
On the other hand, all the examples , from the Apple source, are based on
C, not on cocoa. Well, does that means that I must rework my program in C
??? Or is it possible to have fraction of the program in C under the cocoa
environment?
You can mix C and Objective-C at will. As long as you pass it a function,
and not a method attached to an object, it should work.