MLL wrote:
> Hi Glenn,
Hey.
> I've been using it : it works fine !
Great.
> 3 comments :
>
> - the indentation for the created "break" lines is wrong
> (they're 5 chars ahead of the "case" instead of 2)
Oops. Thanks.
> - it would be great, if possible, to have some editing
> functions in the textbox titled "HTML for selected FORM",
> such as searching, replacing, maybe deleting & typing,
So, IIUC, you want to edit this so that the resulting XML search file contains
your changes? I'm not sure this makes sense because of the incredible amount of
HTML crud that could be contained by the FORM. Also, when extracting the INPUT
elements from the FORM, the existing HTML DOM is parsed. Changing the HTML
would require forcing those user changes back into the DOM <shiver/>.
The bottom line is that sense the FORM and its INPUT elements are the only
elements extracted, and these can be edited in the resulting XML file, I'm not
sure it's worth the trouble or makes sense to edit them in the wizard dialog. I
put that in there initially to help identify which FORM contained the search you
were creating. When I added the ability to automatically select the FORM with
the active INPUT field, the displayed HTML just wasn't that useful anymore.
> or -let's dream- syntax colouring. What do you think ?
Sure. Again, I don't know how useful the displayed HTML is now. It would be
possible to use a rich text edit field to display colored syntax. What I really
would prefer is one of two things...
1) Using a browser control to render the FORM's HTML. The only problem with
this is that taken out of context of the page it probably wouldn't render
correctly (missing CSS styles, etc.) There's also the problem of having to deal
with client-side script that the FORM might contain (ugh).
2) Highlighting the currently selected FORM in some way on the actual page would
be way cool and helpful. This would probably be difficult considering the
wizard dialog is modal to the IE window.
> - i tried to set 2 switches : "1" and "2". DQSD produces this :
> //var args = parseArgs(q, "1, 2");
> //if ( args.switches.length > 0 )
> //{
> // switch( args.switches[0].name )
>
> is it on purpose ? Shouldn't it indroduce some loop like this one :
> for( var j=0; j<args.switches.length; j++ )
> {
> switch( args.switches[j].name )
> (and it works in all cases, even if j == 0) ?
Not necessarily. If my search expects only one switch, then there's no need to
loop through the entire list of switches. Any other switches are simply
ignored. If your search requires multiple switches, then the loop would make
sense. Maybe it makes sense to add a '[ ] All switches are mutually exclusive'
toggle to the wizard. If this was _not_ set, the wizard would gen the loop,
otherwise it would gen code like it does now. But, there are probably other
constructs that would make sense in other situations. So, like most code-gen
wizards, it can only take you so far. Anyway, I'll think about it some more.
Thanks for the great feedback.
Later,
Glenn
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Dqsd-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dqsd-users
http://sourceforge.net/mailarchive/forum.php?forum_id=8601
