On Thu, 2007-12-06 at 18:48 +0100, Guido Diepen wrote: > > > 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 I'll have to knock up a little utility to test all these extensively. > > 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. > > It looks a little odd to me as well, unfortunately I have no idea what the device expects from these calls besides what is in the code. Do you know of any reference material relating to what should be sent over the wire ? > > > > 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. > I'll definitely keep them in mind, good idea. What I could really do with is a crystal ball telling me what to send :) Mark ------------------------------------------------------------------------- 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
