Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3368: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3370: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3371: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3372: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
OrbWorks Community Forum • View topic - Getting Object as return from COM method/property

Getting Object as return from COM method/property

Discuss PocketC for CE (including Desktop Edition)

Postby olegyk on Thu May 03, 2001 5:39 pm

As illustrated in "pcfilesys.h" it is possible to get scallar or self-contained types as return values of COM methods/properties, e.g.
<pre id=code><font face=courier size=2 id=code>
string retpath;
:
cominvoke(ptr,dispid,&retpath);
alert(retpath);
</font id=code></pre id=code>

The corresponding IDL definition will look like:<pre id=code><font face=courier size=2 id=code>
HRESULT NextDir([out,retval] BSTR* val);
</font id=code></pre id=code>

But we have a problem, when the retval is an Object, e.g.
<pre id=code><font face=courier size=2 id=code>
HRESULT selectSingleNode([in] BSTR s, [out,retval] IXMLDOMNode** resultNode);
</font id=code></pre id=code>

Intuitively we try to treat this as a request for pointer to pointer, in which the IDispatch for the Object will be put. However, the following approach fails:
<pre id=code><font face=courier size=2 id=code>
ponter p;
:
cominvoke(ptr,dispid,&p);
</font id=code></pre id=code>
Any suggestions?
olegyk
 
Posts: 6
Joined: Thu May 03, 2001 5:00 pm

Postby guy on Fri May 04, 2001 7:36 am

The problem is that PocketC pointers aren't really pointers at all. PocketC allocated memory has a life of its own and no relationship to real memory.

PocketC has no mechanism for accessing real memory by its address. There may be a way to fudge it.

PocketC memory can be imagined as an array of structs. The struct contains some variable type fields and a union containing on field of each type. When you malloc one unit, you get a whole variable/struct.

pointer variables contain an integer which identifies the "slot in the array". malloced stuff runs up from 1, declared variables have large values. 0 is null.

String variables contain what I think is the real address of the string (but this may just be a C++ string class, not the actual memory).

PocketC has a settype function that allows you to change the type of a variable. Any fudge would have to involve getting a real address returned into an int variable (or a pointer, the two are identical), then changing the type of the variable to a string.

This would then make the PocketC runtime deference the pointer when you accessed the variable, since it would now be a string.

However,

1. This depends on the way the fields are overlayed in the union.

2. This depends on the way strings are represented in the union.

3. This depends on what PocketC expects to find on the other end of the pointer.

If (OK, big if) this fudge works, then the data can be accessed. For several levels of indirection the trick can be repeated each time by copying the first four characters of the "string" into another integer variable and changing the type again.

Maybe I'm just missing the point, or suggesting something complicated when something easy would do.


Guy
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Postby olegyk on Sat May 05, 2001 3:41 am

I am glad that the topic at least got started. OK, here are several notes to get the point closer:
<ul>
<li>In COM, pointers (here and below we will mean pointers to objects, as opposed to BSTR, etc.) are not used for dereferencing, i.e. accessing the elements of underlying data directly. For that you use methods, propputs and propgets. </li>
<li> What pointers are used as is arguments to these methods, propputs and propgets, when we want to operate over objects, including the one whose method or property we are accessing (the first argument of <i>cominvoke</i> in PocketC):
<pre id=code><font face=courier size=2 id=code>
obj2 = obj1.parent;
obj1.method1(string1, obj2, string2);
obj3.next = obj2;
</font id=code></pre id=code>
These calls can be defined in IDL as
<pre id=code><font face=courier size=2 id=code>
interface IObj {
[id(0x0000)]
HRESULT method1([in]BSTR s1, [in]IObj* o, [in]BSTR s2);
[id(0x0001), propget]
HRESULT parent([retval, out]IObj** o);
[id(0x0002), propput]
HRESULT next([in]IObj* o);
}
</font id=code></pre id=code>

</li>
<li>with this in mind, my very concrete question is, <b>what PocketC datatype we need to specify as the COM object paramenter</b>, i.e. whose IDL definition is

<pre id=code><font face=courier size=2 id=code>
ISomeObj **obj
</font id=code></pre id=code>
</li>
<li>Thus far, here is the list of types/structured, which failed (viz cominvoke returns 0 and the passed value and its referee remain unchanged):
<pre id=code><font face=courier size=2 id=code>
// sizeof(int)==sizeof(void*)==4 bytes
int i;
cominvoke(p,dispid,&i);
</font id=code></pre id=code><pre id=code><font face=courier size=2 id=code>
string s="0123"; // 4 bytes
cominvoke(p,dispid,s);
</font id=code></pre id=code><pre id=code><font face=courier size=2 id=code>
pointer p;
cominvoke(p,dispid,&p);
</font id=code></pre id=code><pre id=code><font face=courier size=2 id=code>
int a[1];
cominvoke(p,dispid,a);
</font id=code></pre id=code><pre id=code><font face=courier size=2 id=code>
pointer p=0; p=malloc(1); settype(p,1,'i');
cominvoke(p,dispid,p);
// or
cominvoke(p,dispid,&p);
</font id=code></pre id=code>
</li>
<li>My pessimistic suspition is that we have the case of "the current desing" not being able to handle the IObj** cases at all, and just having to fall off into the fail state. %-(
</li>
</ul>
olegyk
 
Posts: 6
Joined: Thu May 03, 2001 5:00 pm

Postby olegyk on Sat May 05, 2001 3:44 am

A correction:
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
cominvoke(p,dispid,&p);
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
This, of course, should read as different p's, i.e.
<pre id=code><font face=courier size=2 id=code>
cominvoke(ptr,dispid,&p);
</font id=code></pre id=code>

Sorry.
olegyk
 
Posts: 6
Joined: Thu May 03, 2001 5:00 pm

Postby guy on Tue May 08, 2001 9:13 am

OK. I wasn't talking about pointers to objects. I was simply talking about the return value itself, regardless of what is being represented. This is nothing to do with using pointers to get fields from an object. It's to do with trying to get a return value put where you want it so that you can use it.

PocketC has to "double buffer" values returned by pointer when it calls into real code from its interpreted runtime system. It sets up the call with local target return variables, makes the call, then tries to get what it thinks is the returned value (whatever it represents) into a PocketC format variable that the runtime can use. This involves conversion, copying, and probably discarding anything it's not prepared to recognise. It may even copy back the wrong value. This is true of many of the interface functions provided by PocketC (it almost neuters the sendmsg() function for example).

All you want is a 32 bit value back unchanged. If PocketC doesn't support returning this value then you have to resort to unconventional means.



Guy
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Postby olegyk on Wed May 09, 2001 6:36 pm

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
All you want is a 32 bit value back unchanged. If PocketC doesn't support returning this value then you have to resort to unconventional means.

Guy
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Yeah, like writing a DLL which does the trick. <img src=icon_smile.gif border=0 align=middle>
olegyk
 
Posts: 6
Joined: Thu May 03, 2001 5:00 pm

Postby guy on Thu May 10, 2001 10:44 am

I agree. The pain is that you then have to build the thing for every platform combination that you want to support.

I tried messing around with changing variable types and the address for a string doesn't sit in the same place in the variable union as the value of an int (or doesn't appear to). Well it was worth a try.

I've been pushing Kevin for some time for a function or operator that returns the real address of the storage for a variable.

Better that the runtime properly supports all types that you may need to pass to the underlying APIs. This maybe would be best served by a decent external definition syntax.



Guy
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom


Return to PocketC for CE

Who is online

Users browsing this forum: No registered users and 2 guests

cron