In my last post I write about being able to programmatically scroll through an M3 list, you may want to do this for several reasons – such as populating the ListView so you can enumerate through its entire contents and not just the records that were initially retrieved.

I vaguely mentioned that the reason I was looking in to it was due to some very specific requirements – we have a mod in PMS050 which makes manufacturing reporting for ‘normal’ staff challenging. Closing a MO ends up being done through PMS050 panel B. Panel B doesn’t have much in the way of filtering.

As a temporary work around I decided that I would add a TextBox for an product number (ITNO) and a button which would initiate a script that would look for the Textbox value in the first column of the ListView, if ITNO wasn’t found, it will simulate two page downs and then check to see if it can find ITNO – this process will be repeated until it finds ITNO or we reach the end of the list.

There were a number of challenges around this:

LSO will retrieve a small sample of records and display them. As you start scrolling down a ListView it will retrieve another block of records to be displayed – we never know exactly how many records make up the ListView. The ListView itself has no idea either. This makes determining if we have reached the bottom of the list challenging.

When LSO requests its next set of records it takes time, during my testing my loop would complete up to 4 times before the new records were retrieved and added to the ListView – so I couldn’t compare a previous record count (ListView.Items.Count) against the record count after the page down.

How do you simulate the key depression and what are the ramifications?

Addressing point 1, this took a while to resolve until I caved and investigated the LSO UI assembly. Smart Office wraps a WPF ListView in the ListControl object, and one of the properties that the ListControl exposes is HasMoreRows. HasMoreRows is Boolean and will be true as long as there are more records to retrieve. Once we have hit the last it will be false.

Point 2, once I discovered this variable, issue two just disappeared 🙂

Point 3, well, that’s discussed in my previous post, however this did have some unforeseen issues. The usage of SendKeys from the Windows.Forms assembly will send the keys to the currently active Window and control. If you open another Window then it will take the focus and of-course will start receiving the SendKeys events – not so much of an issue for most situations but it is a problem nonetheless. I did take a look at creating a KeyEventArgs object and using the RaiseEvent of the ListControl which I would expect to get around the issue but I couldn’t get it to consistently work – but that’s why we have versions of software 🙂

Below is a snap of the final product.

Now with that over, here’s the code that I will be distributing to my user.