Starting a new thread here! This code from a javascript, trashes two fields when used as part of the header in the preview_form. Can someone PLEASE help me modify it so that it:

either -- selects the values sent via the submitted add form

or -- writes the values to the database that were submitted in the add form and NOT overwrite them unless new values have been specifically chosen (don't overwrite with null values!)

Here's the pertinent Javascript code, I don't have a clue how to change it to achieve what I'm looking for though, so any help would be greatly appreciated. (I know the script is working other than this overwriting submitted values on the preivew form only though).

new Array(
new Array("Please Describe below", "Please Describe below")
)
);
function fillSelectFromArray(selectCtrl, itemArray, goodPrompt, badPrompt, defaultItem) {
var i, j;
var prompt;
// empty existing items
//for (i = selectCtrl.options.length; i >= 0; i--) {
//selectCtrl.options = null;
}
prompt = (itemArray != null) ? goodPrompt : badPrompt;
if (prompt == null) {
j = 0;
}
else {
selectCtrl.options[0] = new Option(prompt);
j = 1;
}
if (itemArray != null) {
// add new items
for (i = 0; i < itemArray.length; i++) {
selectCtrl.options[j] = new Option(itemArray[0]);
if (itemArray[1] != null) {
selectCtrl.options[j].value = itemArray[1];
}
j++;
}
// select first item (prompt) for sub list
selectCtrl.options[0].selected = true;
}
}
function init(frm) {
var combo = frm.Select_Box;
var combo2 = frm.Category;
frm.category.value = combo.options[combo.selectedIndex].value;
frm.occupancytype.value = combo2.options[combo2.selectedIndex].value;
}


THANKS!
Lynette
Hollister, Ca

Unrelated... but on html_page_top you have:

new Array("Please describe below", "Please Describe below")

and under html_imp_preview you have:

new Array("Please Describe below", "Please Describe below")


It's not going to solve your problem but it will prevent a future one.

On the "select" issue it sounds like the proper item is not being chosen upon preview and therefore the wrong value is being passed to the db. Is this right?

If not, ignore everything below... If so, this may help you to some degree. On my selects I had to do one of the following:

print qq|
<SELECT NAME="chicks">
<OPTION VALUE="sue" |; if ($rec{'chicks'} eq "sue") {print "SELECTED"}; print qq|>sue
more options - same format
</SELECT>

OR

<SELECT NAME="chicks">
<OPTION VALUE="$rec{'chicks'}">$rec{'chicks'}
<OPTION VALUE="sue">sue
</SELECT>

The reason was to keep the wrong select options from finding their way into the db upon "modifying".

Like I said, this probably won't help you any, but I thought it couldn't hurt to try.

Good Luck!

that is what I had previously suggested



that is Links way for doing it in templates. I was sure that it had been previously done somewhere in DBMAN just a matter of finding it.

That will solve her problem with the first SELECT statement. But then she has this amorphous SELECT statement



There are no options to select!!!

there needs to be some way to automatically populate that second SELECT statement.

Absent that:

Since the solution above would fix the first SELECT statement, she could use the ONSUBMIT to deal with the second SELECT statement (if she syncs up the variable name between the form and the database she could eliminate the need to deal with the category variable in the init function). Use an IF statement in the init function to test the value of combo2.options[combo2.selectedIndex].value;. If it is blank or has a length of zero, do nothing. Otherwise, the value of occupancytype could be transmitted from the following INPUT statement placed early on in the preview page.

<INPUT TYPE=hidden NAME=occupancytype VALUE="$rec{'Category'}"> The Category variable here comes from the second SELECT statement on the add page.

Well, I'm not sure about using $rec{'Category'} so someone from the DBMAN could do that part.


Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

OK, I cannot tell you how to do it with Javascript, sorrry.


This can be done in Perl either within your modified html_record_form (as Watts and esm suggest) or as a different sub. I can see that for the large number of options in your first select box that coding within the html_record_form would be lots and lots of if statemnets, so a new sub with a loop may be more efficient and better allow for any addtional options added in the future. However, I only know how to do that based on the build_select_from_db MOD.


Again having no idea what the Javascript is doing, here is a "quick and dirty" way; lets see .... *thinking*

In preview screen, do not allow editting! yea that's it.

so you don't need the js to generate the select boxes in preview screen. Just make 2 buttons in preview screen,

Add record (which adds it)

and

Edit record (which is javascript to go "BACK" like the BACK button.

Hey I said "quick and dirty".

I'll give it some more thought.

This is a good idea! It will get me there quickly while I continue to search for the longer term answer. No reason the user HAS to be able to edit the record on the same form! I mean, really, convenience for the user??? <just joking!> The only thing that wouldn't happen is the form would not pick up the existing values on an edit. I'm sure that's why the mod has it all on the same form.

Thanks, this is better than my idea of stripping the select boxes and using text boxes on the preview form or dumping the preview mod altogether.

Lynette
Hollister, Ca

No the selects fill correctly. It's that the preview mod reloads the script (so the record can be edited if needed) and when the script reloads the values are reset to null --- if I select the matching values in the editable form and then save my record, the values save correctly. This is a problem with the javascript resetting those values before the record is written to the flat file!

But I like your select suggestions and have some other uses for that info! Thanks!

That's the whole purpose of the javascript. It fills the second select based on the content of the first select from the new array statements in the script. The selects aren't the issue anymore, I've straightened all that out. The issue is the preview form - which allows the user to see the long_record format AND to edit the record on the same form. Being able to edit the record means loading the script again for the form and that tramples the values that are seen in the long_record form so that nulls are saved instead.

you could post it here: http://forums.webdeveloper.com/index.php?s=

at least the javascript part for the second SELECT statment.

If they could solve the second part for you, you'd have it licked.

The IF statements are not too difficult. After the first one, the others are pretty much cut and paste.

Or, as suggested, just use the preview page for viewing and the back button or javascript back to the add page to make changes. Won't solve your modify page ( is there one in DBMAN? ) but, hey, you didn't ask about that one...!

Let us know if you ever get it solved. I'd be interested in the solution to that second SELECT statement.


Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

well I found out something interesting about the Preview mod. When you strip the add_form out of it and insert a back button for the editing, then click on add it! you get an error. So this explains the javascript problem. The preview mod, is submitting the data from the add_form to the database which is not setting up with the previous values.

So, If I could get those previous values to pass through to the form I'd be all set... I can either go back to my idea of a secondary modified add form that uses text boxes rather than the javascript select boxes... or I can hope I get an answer from the javascript places I put my modified question!

Thanks for your help guys. You really helped me narrow this down. I'll post the answer, just in case some one else comes along looking for a solution like this!
Lynette
Hollister, Ca

OK, hope it works out. I visited your demo and added a record, so now I see the whole thing better.

Just another "work around" if you can follow this;

on the second page (preview plus edit form), the editable part, for the fields Category and Type, present the current values using dbman variables, just like in the Preview section, then if the user needs to edit these 2 fields, have a button they hit to run the javascript to build the select list. Else they can edit any other fields without running the javascript. The java script will still not make the current values the selected, but the user can look at the Preview section to see what they had before. If you tried, you could probably set the javascript to run if the user clicks into the general area of category or type, kinda a hiddden button.

Oh Well here's to hoping you get a javascript answer.

That just sounds really complicated to me.

I'm thinking if I write the hidden values twice, once to the data fields (category and occupancytype) and once to a temp holder like cat1 and occ1, then the second time the form loads, the data would be wiped out of the fields, but I could compare cat1 to category and replace category with cat1 if category=-1 or is blank? same for occ1 to occupancytype?

This is looking like if I can figure out the code in the hidden input fields it would be better than trying to further manipulate the javascript.

Thanks!

Lynette
Hollister, Ca

I never got a good javascript answer so I went back to my html.pl and changed the preivew form so the slect boxes aren't used. It uses text boxes instead, this saves the data correctly to the file which is the most important thing, it gets me out of the banging my head against the javascript wall (also important!) AND, if the user does need to change those fields, they can just use there browser to go back one screen and resubmit the form.

That's my workaround for now. It keeps me moving ahead!

Thanks for all your help in this issue!
Lynette
Hollister, Ca