> > If you could provide me some info of what exactly goes wrong I might be
> > able to figure out what is causing the errors in your case. (Problem is
> > that I don't have WM2003 device, only WM6....)
>
> Short answer is error code 31 from CeRegEnumValue in list_key() using
> synce-registry tool.
Is enumKey working without a problem and the problem only occurs with
enumValue? Could you test that one? Because enumkey was also already
implemented in rapi2, I only worked on enumValue and QueryInfo.
> I think there may actually be a problem with CeRegQueryInfoKey and
> CeRegEnumValue (in registry tool) in rapi1, the results I got back from
> a bit of testing were unexpected. In fact I've written myself a reminder
> comment in my gtk registry tool about CeRegEnumValue not being reliable.
As mentioned before, the thing that struck me is the fact that you write all
kinds of things with optional things etc. Furthermore, you send things like
the actual lpszValueName over the line (line 225 and 226 in registry.c). The
idea I had when implementing the function in rapi2 is that you only want to
tell what the size of buffers is that you have such that the device knows
whether to send you the information or not. Maybe not even that. It could be
that you only have to supply the handle to the key (and optionally the
dwIndex) and that you will always get all information. I would have to test
some more things for that also.
>
> I've had a quick look, I don't really know enough about rapi though,
> want to give me any tips from when you fixed the rapi2 versions ?
Hope you understood the above lines :) I want to point you to the extra debug
routines I implemetned in rapi_buffer.c though:
rapi_buffer_debug_dump_buffer
and
rapi_buffer_debug_dump_buffer_from_current_point
You supply it with either the context->recv_buffer or the context->send_buffer
and a char* as a description and it will print out the current recv or send
buffer. This helped me a lot to figure out the problems with the read_string
method. The second method only is useful with the receiving buffer, since you
can call this after each rapi_buffer_read_* and it will dump the buffer from
the active index.
Regards,
Guido Diepen
--
Aviation is proof that given the will, we have the
capacity to achieve the impossible.
--Eddie Rickenbacker
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
