Caution - > This is a lengthy post...
Voodoo: Things I have found, thus far...

Please keep in mind that I, like numerous others, would like to see this product blast off and that I am just trying to share my experiences thus far, in order to share info that may be helpful for further discussion,etc,etc...

I've ordered and received my Voodoo and plunked thru the Voodoo WConnect tutorial and found the following
things:

1. Warning. Pay attention when you cut/paste code from the tutorial docs
into your tutorial program. The links and codings are not all that correct. One link calls Customer.voodoo after having named the function call CustomerList. Other
such minor errors exist in the tutorial docs. Sometimes the function call
says Voodoo .. when the function was to be set up as Voodoo1, etc.. You just
have to pay attention to the function names and classes being set up and
make sure the calls are right before you try to run them...

2. The WebDataForm - simple data entry example.

a. The buttons on the toolbar are clicking twice .. once on the button and
once on the image. Therefore, you get two clicks when clicking ontop of the
image.

b. Pressing the Previous button .. this fires the Next() event. Doh!!

c. The Previous Event() does not appear to exist at the moment.

Here is the sample code from the Navigating Tables topic:
(Notice that the function following the Next() function is not properly
defined..it appears to be the Previous function ...)

DEFINE CLASS OurForm AS WebDataForm of voodoo.prg
RecordPointer = -1
FUNCTION Init
THIS.PreserveProperty('RecordPointer')
RETURN DoDefault()
ENDFUNC
FUNCTION OnLoad
USE Customer
* Add data bound controls here...
DoDefault()
ENDFUNC
FUNCTION Next
GO (THIS.RecordPointer)
SELECT Customer
SKIP
THIS.RecordPointer = Recn() ( <---warning: function is Recno()! )
ENDFUNC
FUNCTION
GO (THIS.RecordPointer)
SELECT Customer
SKIP - 1
THIS.RecordPointer = Recn()
ENDFUNC
FUNCTION Destroy
USE IN Customer
ENDFUNC
ENDDEFINE

..you can change it to say FUNCTION Previous ... but the Previous button
still fires the Next() function anwyway...

d. I can find no documenation for the event functions of the WebDataForm
toolbar... missing are Init(), Next(), Previous(), Save() .. SaveAndCancel()
.. if that's what its called? There may be others.

e. The Save button is not automatically binding data back to the customer
database table.

I have taken a pretty close look at this as there have been numerous posts
on the wwThreads web-board regarding this, ...quite a bit of confusion as
well ... posts of people trying to figure out and work around the problem by
using the Request object.... ... Anyways, this is what I have found:

I saved four print-screens and posted them at the following link:

http://208.181.38.133/voodootest.zip

..I'l leave them up there for a while if anyone is interested in reviewing these in reference to this post. They are prt-screens of code where I ran into the errors ... during this process... I refer to them in this message.

- The tutorial example topic 'Understanding Conventional Data-Binding -
Creating a Simple Data Bound IMput Control' works to explain how Voodoo does
data binding to native VFP tables and other data-source types. This help
topic indicates ..

"Note that the data source has to be available whenever the Render() method
is called. Therefore, the right time to close it is either in the Destroy()
of the control or after the Render() method of the page has been called."


This does not appear to be correct - or - appears to be a problem. The tutorial example leads you to close
out the table after the render() call has been made. While that nicely
closes the file after the initial page has been rendered, it is causing the
problem that has been posted by numerous individuals on the web-board----->
the save button does not work.

The reason the save button does not work is due to what Markus has kind of
eluded to .. that is, there is some sort of data issue that is causing the
postback to not save the bound data back to the table.

The Customer table is not available!

If you are also looking at the prt-screens that I've made available, please refer to
postbackerror1.bmp. Note that the bindpostback function is using the vfp
type() function to examine the variable typing of the controlsource ... it
is returning "U" for unknown ... and this is because the table is closed!

The end result of this is that none of the data is being returned back to the
customer table.


- The conventional data-binding is not working at all. (Yes, its getting a
little worse.)

As a test, I simply opened the Customer table in the main WConnect routine
and left it open. I changed the example code so that it simply selected the
Customer work-area ... and I commented out the use in customer line after
the render() call....

This corrects the problem of the table not being available. As a result,
the Type() function does not return "U" - Unknown ...

However, it appears to expose a more complicated issue with the conventional
data-binding. The current code in there can't manage the various data types
in a VFP table. I refer you to prt-screen postbackerror2.bmp...it now type
mismatches when putting back the data on anything but text. Naturally, the
data coming back from html is text .. whether numeric or not .. .its a
literal string. This code needs a case construct on that type() in order to
properly transform (coerce) the text back to the proper allowable value of
the database field. The current code does not have this at all.

Refer to postbackerror3.bmp which illustrates the problem .. as the
processing has stopped (choked) on a numeric field ... and this.value is a
literal string .. the replace statement is crashing.

I prt-screened the entire BindPostBack function so that you can get a better
sense of where this issue lies.
(Note the curious *perhaps* comment re: XML on the IF/Else construct... oops
:-D...)

I have *heard* some frustrations on the Web-board regarding figuring out how
to make all of the work right .. to get it going....and that the examples
are not quite full enough yet. I would have to say that I believe that some
of that is fair criticism ... Nobody likes debugging tutorial examples, and
the documentation IS missing stuff.

However, its pretty close.

The beefier the examples and the more accurate those examples, then the
faster programmers will adapt to and use this product.

It has a LOT of merit!

I wish I could fix the above to get the conventional data-binding working to
vfp tables. It then, wouldn't take too much effort to make a fuller example. As
an exercise, I will certainly go thru making my own and post it.

I hope to see feed-back from any new Voodoo-ists on the above... as well as any guidance and/or comments from EPS(Markus)

Thx! Scott Barker
:-D