Search & Select Forms for custom visual assit

[kavehm]

As business need requires an override of a visual assist, so i created a new search and select form. The form is based on a BSVW combining F03012 & F0101 & F0115, but when I try and pass the AN8 GC column back to the override, it doesn't pass the correct GC value?!? If i remove 2 of the three files from the BSVW, the Search & Select overrides correctly and passes the correct value back. Anyhoo, my question is this, can search & select forms have multiple files in the view being used? Any ideas would be much obliged!!!

 

[BOster]

Yes you should be able to have multiple tables in your BV used in a search and select. If you are returning address book number, I would make F0101 the primary table and make sure the first BC param in your form interconnect is AN8.

 

[kavehm]

That did the job! So the key needs to be unique, who'd a guessed?!?! Makes sense....kind of.....at least it works!

 

[Zoltan_Gyimesi]

Hi kavehm

Just an addition to Brian post.

A.)
If AN8 is the first DSTR member in your Form Interconnect, then on the Button Clicked event of Select simpy assign
FI Addres Number = GC Addres Number (Fxxxyy)

B.)
There is an other way to play flexible with Visual Assist. Briefly:
- if the DD item behind the control has no Visual Assist originally, then on the control Properties > Overrieds override the Visual Assist with any form (e.g. with yours)
- place your logic to the Visual Assist Button Clicked event of the Control
- first issue a "Suppress Default Visual Assist Form" System Function call (General category)
- call your S&S or any other type of form via Form Interconnect
- advancing the logic in this event and in the called Form, you can do almost everything

Some advanteges:
- you can pass input parameters to the called form in FI DSTR, e.g. for pre-filtering purpose
- you can get back more then one value from the called form
- you can add any special logic dealing with Visual Assit call
- based on e.g. some values, you can call different forms

I did it many times. Just a hint:
- add a 'cSelectReturned' FI DSTR member to the called form
- map variables to FI DSTR when you call the form instead directly FC
- assign the values to FCs only, if cSelectReturned is eual to '1'
- of course, you can deal with FI cSelectReturned member in your called form

Hope, maybe this will be useful for you in the future.

Regards,

Zoltán

 

[kavehm]

Thanks Zoltan, i had tried many of your suggestions as well, from using a headerless detail form instead of a Search & Select, to get it to work, but the problem seemed to be with the bsvw of the called search & select form. I had he F03012 as the driver instead of F0101. Give it a try, it was very strange the results being returned thru the dstr to the calling form (even in debug, the called form had the correct value in the FI variable, but once it was passed back to the initial calling form, the value would be very different). Anyway, changing the driving table in the bsvw of the custom "search & select" form to F0101 seemed to fix it. Still unsure why.....guessing it has something to do with unique key values...