SearchOptions - Specifying columns to include

Apologies if this has been asked and answered, but after a few days of trial and error w/Google search, I thought I’d ask… I’m trying to display a search dialog on the UD100 table.

ArrayList searchKeys = new ArrayList();
searchKeys.Add("Key1");

Ice.Lib.Searches.SearchOptions searchOpts = new SearchOptions(SearchMode.ShowDialog);
searchOpts.SelectedKeys = searchKeys;
searchOpts.SortDescending = true;
oTrans.InvokeSearch(searchOpts);

This works fine, even performs the request sort on the primary (Key1) field.

But I’m trying to figure out how I can limit the columns displayed in the dialog to JUST the Key1 field. As you can see, I thought I’d get clever with the “SelectedKeys” property on searchOpts (No joy).
Once I’m able to figure this out, I’d like to re-title that column to read “Ticket Number”.

A) Any thoughts on how to accomplish?
B) Anyone know of a good reference on SearchOptions and searches in general (coding)?

Thank you.

You’re better off utilizing a dynamic query for this if you want to customize the return.

Thanks @Aaron_Moreng. I’m aware of that option - and I may use it.
What I don’t know, and I’m curious about, is if the dynamic query is the ONLY way to customize the return - in terms of columns returned, and possibility column names. Do you have any info on this?

So it seeems that the SearchOptions object isn’t documented? Its methods and properties are listed in the Object Explorer, in Customization mode, but the object explorer doesn’t provide any textual guidance on the use of its members. The BO guide doesn’t include this object (or any of the search methods by adapter [strange]).

I noticed that @Chris_Conn responded (in October) to your May 2017 topic Launch Search and return selected value. Chris was able to use one of those methods to filter the data.

There are a number of additional methods, one of which MAY allow specific columns to be returned? My guess is that there’s an article or answerbook somewhere…

I think it returns a getlist on the BO when the search is called. The WhereClause described in the link is the same as what the GetList method accepts. I like to visualize this with the BL Tester utility.

Ultimately, I believe that the SearchOptions object is really a wrapper over GetList/GetRows in an attempt to make it easier to use.
Understanding your requirement will help steer you in the right direction though. It sounds like you want a custom view of the data returned to the user rather than a behind the scenes lookup/return, so I’d still opt for either a dynamic query or invoking a quick search with custom BAQ behind.

After seeing your post yesterday I dug into the SearchOptions and SearchForm. From what I see, it’s a pretty rigid construct, not much room for modification.

With that said, @Aaron_Moreng’s suggestion is the easiest. You may also be able to make a special search (BAQ or quick search) and call that instead - although I’ve never done it.

It wouldnt be overly complicated to roll you own search form (ala dynamic form) and write your own logic for it using GetRows, GetList, or BOReader to populate it.

@josecgomez helped me with this once, but it was to call a custom search form with a quick search behind.
The meat of it is in the front, which is utilizing the ProcessCaller.InvokeAdapterMethod. Obviously this is specific to my need, but hopefully it makes sense.

if(args.Tool.Key == "Disposition Inventory Non-Conformance")
		{
		
			//launch special search by Donor Number to retreive any non-conformance lots associated. Return value is NonConf.TranID
			object ret = ProcessCaller.InvokeAdapterMethod
						(oTrans.EpiBaseForm, "QuickSearchAdapter", "ShowQuickSearchForm", new object[] 
						{oTrans.EpiBaseForm, "YourQuickSearchHere", true/* multi-select */, new DataTable() });
			// user cancelled
			if (ret == null) return;		
			
			ArrayList list = (ArrayList)ret;   

			for(int i=0;i<list.Count;i++)
			{
				string value = list[i].ToString();
				int convertValue = Convert.ToInt32(value);

				adapterInsp.GetByID(convertValue);

				oTrans.NotifyAll();
				oTrans.NotifyAll(EpiTransaction.NotifyType.Initialize, edvinvView);
			}		
			oTrans.NotifyAll();
			oTrans.NotifyAll(EpiTransaction.NotifyType.Initialize, edvinvView);	
			Erp.UI.Controls.Combos.InspectrCombo cmb = (Erp.UI.Controls.Combos.InspectrCombo)csm.GetNativeControlReference("69eac31b-3e9c-4e3f-9962-45220b10f738");
			cmb.Focus();
		}
1 Like

Gents, I truly appreciate the feedback. I’ve sortof resigned myself to the likelihood I’ll have to create yet another simple BAQ that just sits out there adding to the many other “supporting BAQs”. I really wanted to keep all functionality within this customization.

@Aaron_Moreng, Thanks for the helpful info - including your last post re: the Quick Search (also requires a BAQ), thanks also to @josecgomez, by reference. Your suspicion that the InvokeSearch w/SearchOption wraps the BO methods makes perfect sense and makes testing possible with the BL tester.

@Chris_Conn, thanks for the followup, and confirmation that these methods are fairly rigid. The ability to specify, even by index, the columns to return just seemed too obvious for a developer to miss - I may look into the, roll your own, option - maybe find a way to make it reusable. If I’m able to do that, I’ll post it.

Thanks again!

2 Likes

Wow. Just read a post from @hkeric.wci that totally solves the issue.
Using his code, I can specify the columns to display AND the titles of those columns! Just wow!

2 Likes