Like the nice INFLD GUI Auto-complete feature! and Jack your example INFAC1 works well, just one question how can I set the position and size of the Auto Complete box (for example if the INFLD is on row 23 its nearly off the bottom of the screen etc) :rolleyes:

INFLD ROW 7


INFLD ROW 23

PS.
Also would it (Auto Complete box) trample on/delete/effect any controls if they were underneath ?

To answer your last question first, indeed there is a bug which 1181.2 fixes (or will, as soon as it is released in a few hours), in which controls covered up by the list box may "get disappeared".

As for the question of whether to position the list box above the edit box if too close to the bottom of the screen (like combo boxes do), I suppose that makes the most sense. (I was hoping I could ignore the problem and count on these kinds of fields typically being near the top of the window, but I suppose that was wishful thinking.)

I'm not sure whether it should (or must) be based on the relative proximity to the physical edge of the screen or the logical edge of the window. The combo box works relative to the physical edge, but in this case the implementation uses XTREE internally, and I don't think it is capable of extending outside the parent window. So I'd need to experiment with it a bit.

Stay tuned...

(BTW, I have a much better, more realistic sample program on the way, using a list of all the US cities.)

Cool, i'll Stay tuned... and also look out for that realistic sample program. All in all a nice little INFLD feature.

OK, try the 5.1.1181.2 from
http://www.microsabio.net/dist/51dev/bin-win

notes:
http://www.microsabio.net/dist/51dev/ashdevnotes.txt

new sample program (and components): http://www.microsabio.net/dist/soslib/infac2.bp
http://www.microsabio.net/dist/soslib/uszip.def
http://www.microsabio.net/dist/soslib/bldzip.zip

Note that the uszip.def and bldzip.zip belong in [908,48], while infac2.bp goes in [908,41]. (This will be sorted out in the next soslib update, but for now you have to position the pieces manually.)

Here's a screen shot:



The green items at the top of the list are recently entered cities, put there and shaded green explicitly by the app (to demonstrate the possibility of using slightly more advanced XTREE features beyond just a simple uniform list).

The program actually performs ISAM lookups using the partial city name entered in order to build the rest of the list, so it's a bit more realistic than INFAC1 which just generates meaningless patterns of data. Plus there are multiple fields to work with, in order to test for interaction issues between the other fields and the list.

Let me know if you have any ideas on how to improve the concept. One idea I considered was to pass INFLD the name of an SBX to call to maintain the list (vaguely similar to the idea of the file hook subroutines). Surely that would simplify the app, but in the ATE case, it's not clear whether a subroutine running on the client side would have direct access to the data on the server.

Another possible idea would be to pass some kind of file/database specification such that INFLD could retrieve the file data needed to fill the auto-complete list itself. But other than SQL, I'm not sure how practical it would be to come up with a way to specify the file params. (This INFAC2 program provides and example of one of the innumerable complications that can arise - i.e. the city index used to locate cities for the auto-complete list actually is a compound key consisting of city+zip. Thus there may be multiple entries for a given city. Yet it isn't clear how you would generically handle the situation without a lot of custom logic. The current exitcode scheme pretty much allows you as much flexibility as you need, but requires a bit more application programming effort.)

Thanks for the update and all works nicely even on the bottom row now the "Auto Complete box" pops up above/below the INFLD edit box.



Your new example looks good, I also had to download the GTLANG.BSI from SOSLIB, but still got a few IMAM issues to sort before i can run it an I think i've got ISAM disabled on our server and getting all types of stack overflow. (i'll take a look later).

Like the multiple column tweak too!

Also a great idea on passing the INFLD the name of an SBX to maintain the list but it would have to work on the server side rather than the client else as you say how does the SBX access the data, anyway, I have plenty to play with right now - Thanks.

I'm not sure how you can disable ISAM (this is ISAM 1.1, not ISAM-A), but the BLDZIP and INFAC2 programs do use newer ISAM features (4 levels of IDX, 1024 byte IDX blocks). What version is your server side?

BTW, stack overflow is Basic error 33 - could you possibly be confusing that with ISAM erf 33 (key not found)? (I guess if you don't use ISAM, some of these details could be a bit mysterious. Feel free to rewrite BLDZIP and INFAC2 to use SERCH!!!)
(Or, just load the entire USZIPS.CSV into a DIMX array at the start of INFAC2 and change the lookup routines to just scan the array sequentially.)

Or better yet, try playing with the new feature in a real program from your own app.

OK I guess I dont mean disable ISAM but I thought the FILES=600,0 in our miame.ini caused the issue. (as we dont use ISAM)

The AIX Version of Ashell is:
-- A-Shell Version 5.1.1177.7 Up and Running --

I changed the files to about FILES=600,200 and still get some Illegal instruction(coredump) at the end of BLDZIP.

But no worries as you say, I'll have a play and build an example in to our own app. - Thanks.

Hmmm..., while you do that I'll take a look at what might be happening in BLDZIP.

(BTW, it is true that the second value of the FILES=x,y parameter must be >0 for ISAM, but 200 is probably a bit excessive for your case. I think 3 might have been sufficient.)

Your always welcome to do a virtual swim across the pond and VPN in to take a peak if dont see the issue there.

The problem here appears to be between AIX and the use of non-standard levels or block sizes in ISMBLD. (Doesn't occur in Windows or Linux, or if using the standard ISMBLD configuration, so it's probably either a byte-ordering problem or some other difference between the AIX and other implementations of a library routine.)

I haven't been able to track it down just yet, but the short term workaround is simply to remove the /L and /B switches from the two ISMBLD command lines inside of INFAC2. Then ERASE US*.ID? and run it again to rebuild the file. (Unless of course you already have your own real-world test program, but it's always nice to have a standalone test that you can tinker with, free of concerns about breaking your app.)

I quickly removed the L and /B switches in BLDZIP, compiled and tried it but now get:
Related or not im not sure, but no worries as i'll try to build my own little example a little later.

OK you have some how got me hook into this new "Auto Complete" feature and i've create a new little SBX that calls INFLD when the user enter/select a "customer" and list the Auto Complete lists the customer codes and the customer name.

I've created two columns, but as the INFLD for the customer code is only 6 characters long I dont get to see the customers name (2nd column) with out scrolling along, is there a hidden option ive missed to widen the "auto complete box" ?

Regarding the file not found, there are only three used in the program - USZIPS.CSV, USZIP.ID?, and USCITY.IDX. (I suppose that's actually 4, since there is a USZIP.IDA and USZIP.IDX). It decides whether it needs to build the file by checking for USZIP.IDX, so you could get that error if you erased USCITY.IDX but not USZIP.IDX. Or maybe the CSV has gotten misplaced? I guess you could recompile and look at the LSX to get the exact location, or turn on SET TRACE FOPENS ON to see which file it was trying to open.

As for the multi-column issue, you're right that the list box is currently constrained in width to match the INFLD field. Probably it should be determined by the COLDEF string that you pass it.

Surely the next thing after that will be that the requested list width exceeds the screen width, so you want it to slide over to the right? :rolleyes:

I'll experiment with adding a second column to the INFAC2 example (now you're really going to have to get it working!) to show the zip. I was going to do that, but it didn't seem to be helpful, since even if it helped you choose which Springfield you wanted (there are dozens of them), once selected, it would still just be Springfield. The idea only makes sense if the entries in the main field are unique, as in your example (STEVE1, STEVE2, etc.) Perhaps I'll combine the city and zip into one field...

One way of handling the issue, without needing to make the box wider, would be to use the regular proportional font or a smaller font scale in the list (using Advanced Coldef Options ), so that you could fit more characters in the same width. Here's an example just using the normal desktop proportional font:



And if that's not enough, we can scale the font down:



Given that the association between the columns in the list and the physical width of the INFLD box might be rather variable, I'm not sure that scanning your COLDEF parameters to add the column widths is the best way of determining the optimum physical width of the drop list.

Perhaps another parameter can be squeezed in somewhere, but it's already getting pretty dense with all the stuff packed in to SETDEF. Maybe a prefix in brackets....? eg.:

SETDEF = "[+5]1~20~ ~S~~21~5~ ~S~~~" + setlist$

where the "[+5]" prefix meant that you wanted to extend the width of the list an additional 5 column units beyond the right end of the field?

Let me ponder that, but in the meantime, based on how big your font is in your screen image, I'm guessing you could do a lot with just changing it to a proportional one and maybe scaling it down a bit for the list.

OK, I decided that idea worked. So if you download ashw32 5.1.1181.5 you should be able expand and contract the width of the list box somewhat independently of the field width by inserting "[+#]" (expand # columns to the right) or "[-#]" (expand # columns to the left) or just "[#]" (set list width to # columns) at the start of the SETDEF string.

For example, prefixing the SETDEF string with "[+9]" yields this:



Using "[-4]" give this:



Notes: http://www.microsabio.net/dist/51dev/ashdevnotes.txt

Also, FYI, the problem with BLDZIP under AIX was fixed in 5.1.1181.4, which has now been posted. (The auto-complete logic is all on the Windows side, so it doesn't care much what the server version is.)

I see while i've been watching whose doing a deal with who to decide power over here in the elections you have been mighty busy updating this, and nice!! I added a [40] and now the customer and full name shows nicely, Thanks!



Now I may create a similar new SBX for a stock item search. (I know what the down side to all this is, everyone will expect me to update every program with theses SBX where a customer, stock search is used, or worse still ask for the same on all other search! - have I opened a COW?)

btw, I also update AIX to 5.1.1181.4 and the ISAM and INFAC2 all work fine now.

Thanks again.

One qwerk i've noticed is when the "Auto Complete" is enabled and a function key is pressed and trapped by INFLD it displays freaky characters in the INFLD box rather than returning the exitcode.

Regarding the last issue, can you get that to happen in the INFAC2 program (say, by clicking on the ? button) or hitting a function key? (It doesn't seem to happen here for me, making me wonder whether it has something to do with how you coded the button, i.e. whether it uses the pseudo-function key sequence (e.g. "VK_xF12") or raw control sequence (e.g. chr(7)+chr(255)+"12.").

As for the general concept, I had a pretty strong feeling that it could turn into a COW, which may be why it took me so long to get around to it. Perhaps before you go off and replicate variations of your code in a thousand places, we might want to think harder about how to either make INFLD do more of the work for you, or, have INFLD call an SBX to handle filling the auto-complete list (so at least the complications get moved outside your main app and thus might be easier to share in different programs).

The biggest complication with the idea of INFLD calling the SBX directly is that it would have to happen on the client side. So in the ATE environment (where the data is most likely on the server), you'd have to arrange some kind of network communication from the client PC to the server to access data.

In the case of SQL, that wouldn't really be a problem, unless your query required transferring massive numbers of records across the network. But you could presumably handle that by adding a limit clause to the query. You'd also have to figure out how to keep track of the database connection handle between calls (perhaps by passing it back and forth to INFLD, or via a memory module).

For other kinds of files, the file channel would be automatically preserved across SBX calls (because they would all share the context of the main program which called INFLD), so you could just check to see if the file was open with the eof(ch) function (presuming that you had standard file channel numbers for each file). So maybe if you samba-mounted the filesystem on the server, that would work.

Otherwise, it starts to become a Rube Goldberg kind of design, with the application calling INFLD, INFLD calling your auto-complete SBX, it then using something like TCPX to communicate with some other 'server' to issue requests for data, that 'server', etc. Or, even more complicated, your SBX could shell out to an EXE, which then ran some query operation on an external PC database, returning the results in a file, which the auto-complete SBX would have to open and read, and so on.

A related idea would be to come up with a configuration file syntax allowing you to specify the necessary details for a generic auto-complete SBX to do its job. Then, instead of writing a separate SBX for each kind of auto-complete field, maybe you would only need one SBX, to which you could pass a code like "std cust id" or "part lookup by description".

Another idea which is related to auto-fill, but is something that INFLD could potentially do all by itself, is to automatically remember the last N entries in any particular field, in which case it could auto-auto-complete (sort of like typical browsers do nowadays). Probably that would require that you supply a TYPE code to enable it, since you might not want that activated for every single field in your app. (INFLD might uniquely identify the field based on a combination of the program name and field coordinates.) We'd have to decide whether to store all of that info in a "cookie" on disk, or in the Registry. (The disk "cookie" would make it a lot easier to reset.)

Maybe the button in the screen shot was not a good idea as I think its more related to the function key exitcodes from INFLD rather a button, as pressing a button with VK_xF12 works, just pressing F12 with INFLD (to get an exitcode of -12) show the above, if you dont see this i'll dig deeper on Monday.

Meanwhile, all those other ideas are cool and some good time savers (i think) if we worked out what we want, but no worries right now for me as i'll stick to my current two little SBX's and first see what feed back I get from the feature and the selected places I hide this little Eater Egg.

I'm trying to implement auto-complete on a dialog, and every time I populate the setdef, and XCALL INFLD the dialog it's on gets deleted, and the auto-complete XTREE is displayed on the main A-Shell window. Looking at the control dump spreadsheet it shows that the XTREE's parent id is 0. Then if I select one of the items the XTREE is deleted and the dialog re-displays.

Here's the setdef I'm using, it's the example from the docsWhat traces should I turn on to try find out what's happening?

Also, this is ATE version 5.1.1188.6.

infac2.bp does work, so it seems like it must be something I'm doing wrong.

It sounds like the logic in XTREE that automatically saves and then deletes (and later restores) any possibly overlapping controls when the tree is on the main window. This was some kind of workaround for a problem of "bleed-through". Looking at the code, it's not clear what is going wrong, but it may well be that it depends on some quirk which happens to be set here.

If you want to capture a big trace, turn on the GUI flag and then email it to me. (Actually, do it for INFAC2 also.) Comparing the two should reveal why it's acting like it belongs to the main window rather than the dialog.

Try 5.1.1188.7 to see if it resolves the problem. If not, send me the traces mentioned above.

http://www.microsabio.net/dist/51dev/temphold/

OK, let's try again with 5.1.1188.8:

http://www.microsabio.net/dist/51dev/temphold/

I believe the issue I missed the first time around was that your dialog is modeless. The xtree was getting assigned to the default dialog, but modeless dialogs are never the default dialog, so it was being treated as if it belonged to the main window.

That appears to fix it. Is the xtree now being assigned the same parent id as the INFLD?

Good. Yes. Explicitly.

Does auto-complete support ||L?

Sorry, but I didn't really give that possibility any serious consideration. Offhand, it seems like Auto-Complete is mainly of use in situations where you have a huge number of possible matches (i.e. too many to create a traditional drop-down list for). But ||L ( Coded Lists ) are generally employed when you have a reasonably finite set of options (e.g. "01,UPS Ground,02,UPS Blue,03,FedEx,04,DHL,05,First class mail,...")

So how much value would auto-complete be in a case like that, vs. just loading all the options into a fixed dropdown list?

That said, I guess there is no fundamental obstacle preventing us from allowing you to specify a ||L-style setdef list of paired inputs , but only load the description half of each pair into the auto-complete list, and then on exit from INFLD, to do the normal translation, returning the code value corresponding to the description. But offhand I'm not sure that the benefit would justify the potential for confusion.

I like auto-complete for 2 reasons. The first is the same as your point, a huge number of possible matches. But, also for allowing the user to type in more than 1 character for matching.

For example, I've got a user editing dialog; which, you choose the user to edit from a combobox. You can type in the letter "S" and be taken down to the first instance of "S", but if there are a lot of usernames that start w/ "S" you can't type a second filter character, so you have to then scroll through the long list of "S"'s to find the one your looking for. So, auto-complete takes care of this issue by allowing the list to be filtered.

The reason I use ||L in comboboxes is to use the data's primary or candidate key as the code value, and then a description. (e.g. a vendor listing "vend01,ABC Block,vend02,ACME Brick,...) This use is nice for not having to read the data record after selection if you only need the keys. Plus, where we only are using Old ISAM or random data files, it's more efficient when the Description isn't indexed. So, even if I need to read the data record I can use the indexed code value.

OK, I'll add it to the list...

Not too high on the list!

I've found a minor glitch in the XTREE display.

Here's right after pressing the down-arrow. Everything's fine. As you can see here.


But, when I mouse over a row that has a control underneath the auto-complete XTREE the control gets the focus and it appears that their z-values become higher than the auto-complete XTREE. (That's if z-values come into play here.) If I click then it exits with the controls exitcode not -63 for the auto-complete XTREE, but this is to be expected since the control has the focus. It does this for both the INFLD's and the shown XTREE Shown below

We've run into this problem before. Apparently XTREE does respect or benefit from the normal "z-order", such that clicks seem to pass through to underlying controls, and underlying paint events sometimes pass back up to the screen. When XTREE is in the main window, it saves and removes any overlapping controls, but that seemed a bit excessive, so that in the case of an XTREE in a dialog, we just assumed that you wouldn't put one on top of another. However, in the drop-down case, that's hard to avoid.

I need to experiment with it to see if we can get away with something less drastic than removing the overlapping controls - maybe just disabling them.

Another thing for the list...

Going back to the auto-complete with coded lists (||L), I'm not sure I fully understood or fully thought it through.

It isn't possible to convert between the raw and coded field formats while the user is in the midst of taking advantage of auto-complete, because the field wouldn't yet be complete (and thus difficult to match against the coded list).

I suppose we could restrict the list match-and-convert logic to just the initial entry and the final exit. (Although we might need an additional rule to unambiguously distinguish between the initial entry and a re-entry.) But wouldn't the fact that your program needed to do all that intermediate processing relative to the raw field format raise the question of what exactly you were going to gain by also working with the coded formats?

In other words, isn't most of the benefit of using coded lists that they free you from having to work with the raw version of the field in your app (other than to load the setdef list, which could be done from an external table)?

If I understood Stephen, what he is asking is not exactly add ||L to auto-complete but, add to combos the ability to search by proximity while typing in more characters.
Curiously, I thought that combos work like that (multi-character) but, went to check and, in fact, the search is reseted on each typed in character and, repeating the previous character moves to the next item on the list starting with that character.
Is there any switch to allow it? As I know there is one switch to auto-open the combo on entering/editing.

Anyway, I confess that didn't have enough time to try auto-complete for real; I made an attempt and have done something stupid that crashed A-Shell so, I put it away waiting for better inspiration or, better examples during the Conference

But, I think, and correct me if I'm wrong, this feature is not exactly an "auto-complete" option, it's more like an "auto-exit" together with "infld xtree" that can work independently, or not?
The first, auto-exit, allows me to exit from the INFLD after some delay while entering characters, once exited, I can execute whatever I want (even display a dialog with an external XTREE) and return, or not, to INFLD; also is optional to fill the setdef with data to be displayed in the xtree.
The second, xtree/list, I don't know if it only works on returning into INFLD after have exited from it with auto-complete active but, if so, I guess that will not be difficult to make it work independently so, it's a new great alternative for combos (ListBox ?).

I repeat, didn't explore this yet but, for example, if I type in "JORGE" exit with auto-complete and return after assigning to setdef the +100 male sex-symbol list, even if none have jorge on his name, I guess the list will still get displayed, correct?
A truly auto-complete field should highlight all the matching words on the list but, ATTENTION, I'm not asking for this, I'm just saying that A-Shell auto-complete is enormously great and can even be used for other things not related to auto-complete

Jorge, I can certainly see where proximity search with more characters in a standard combobox would be good, but the advantage to the "auto-complete" is that you can filter the list in the setdef as they type. So, what might have been a combo w/ 1000 items, as the user types you can gradually filter it down for a smaller list. Plus, you can have multiple columns displayed, but not matched.

Jack, I see the issue w/ ||L in "auto-complete". Would it work to just return the description part (or what the user has typed) when exiting via the timeout and exitcode=30? When they choose an item via mouse or arrowing down then it returns the matched code.

I think this would probably require using ||S wouldn't it?

To answer Jorge's question, the XTREE and the INFLD field are partly independent, but nevertheless connected. They are independent in the sense that INFLD exits to your application to allow it to load the tree, and the tree contents don't actually have to match the current field contents. (So yes, in your example, the list of sex symbols would get displayed on re-entry to INFLD, even if none started with JORGE.)

And yes, perhaps "auto-complete" isn't a precise description. It's more like "auto-suggest completion options". But it does match fairly closely the behavior of the of the Google search control, which also merely "suggests" ways to complete your search query, leaving you to select one with your mouse or arrows:



Note that it also doesn't highlight the matching entries, because typically that's all the list contains (i.e. matching entries). But, since you have control over the XTREE, you can highlight them yourself. (The INFAC2 sample program, like the Google search control, highlights items at the top of the list that were previously selected.)

But, the INFLD and XTREE controls are connected in that you can navigate between the edit box and the list without exiting INFLD. For example, when you down-arrow from the edit box, the cursor goes into the list (just like it would in a combo box). (That part you could simulate on your own by trapping the down arrow and then calling XTREE.) Also, as you move the cursor through the list, the currently highlighted item will immediately be copied to the edit box. (This would be impossible to simulate if calling the two controls separately.)

Stephen: yes, it would be possible to just return the description part (or more precisely, what the user typed, i.e. what I referred to in my last post as the "raw" entry data) when exiting with exitcode 30 (timeout) and 31 (request for more data). My two problems are:

1. Trying to understand what the point would be. To take your example of a coded list of numbered user names, without auto-complete, if you type in Stephen Funkhouser, you might get back 123. And that would clearly be convenient for your program if it mainly only cared about the numbers, since it could load the coded list in a separate operation and then forget about the names. (Note that you would have to pass the entire list of names to INFLD for this to work, and the user could type "S" and then scroll among the similar names, clicking the one desired.)

In the case of auto-complete, unless you were going to load the entire list (in which case you might just as well have used the traditional combo box method), you would have to have all the logic necessary in your field handler to build a new auto-complete list based on the partial name entered. Wouldn't that code be essentially a superset of the code needed to manually convert "Stephen Funkhouser" back to user number 123? In which case, what did the ||L do for you?

The only advantage I can see here to auto-complete is for the user: unlike the combo box, INFLD+XTREE in auto-complete mode supports progressive multi-character search. (As far as I know, the single-character search logic is a limitation of the standard combo box. Presumably it could be overridden with some kind of hook function, but not easy and probably subject to compatibility issues with different releases of the combo box and Windows.)

So if that was the objective, you could probably just load the entire list of names into the setdef at the beginning, and just return to INFLD with no further action whenever you got exitcode 30 or 31. The only glitch here is that currently when the list is displayed, it relies on the idea that the application would have loaded the list starting with the closest match to the current field, so there is no need to auto-scroll the list. But in your case, if you started typing "Ste", you would expect it to open the list starting with matching fields, rather than with "Aaron". That could probably be fixed though.

2. The second problem is that it is possible to quickly type a value and hit ENTER, in which case the application would never get an exitcode 30. That's ok as long as you pre-loaded the setdef list with all the possible valid choices, but normally, you start out without anything in the list, and wait for the user to to type something before filling it with matching entries.

I wasn't saying that INFLD and XTREE were independent, definitely they must be connected to interact under the internal control of INFLD, as you described; my question was about being able to use each of the two parts of the process independently, such the following examples:
scenario 1 - use auto-complete like a timmer
Just to exit from INFLD and do something (e.g display what was typed in), after what the control is not returned to the field.
scenario 2 - use auto-complete to allow an xtree list for INFLD
On entering the field assign to setdef the data to be loaded into the XTREE; disable auto-complete mode to not exit from the field while typing, and just use the xtree to select.

The scenario 3 is the auto-complete in full mode, where the INFLD exits after a pause of x milliseconds and, it's supposed, the program return to INFLD after fill setdef with data matching the mask filter typed by the user, resulting in an xtree hanged on the field.

Currently, scenario 1 is not properly supported, because if you don't return to INFLD after an exitcode 30 or 31, it will not remove the XTREE. (But I guess you could remove it yourself, and I could make that easier by assigning it a fixed name.)

Of course, INFLD already supports a timeout feature, but perhaps it is not quite as sophisticated as the one associated with the auto-complete. (i.e., the standard timeout has a minimum period of 1 second, and is not sensitive to whether the field has changed, whereas the auto-complete timer operates on a 1/2 second interval, and only triggers if the field has changed.) So, perhaps another type code could be added to get this behavior, if it seems useful.

On scenario 2, again, it is not properly supported, although you could get nearly the same effect by just pre-loading your setdef with the desired XTREE information, and just returning to INFLD whenever it exits with exitcode 30 or 31. The only thing missing would be to force the initial display of the list. And, the matching logic would be superfluous. As with the first scenario, this variation could easily be supported with another TYPE code, if it seems useful (which apparently it does). The result would be pretty similar to the existing combo box though, with the main difference being the greater display capabilities of XTREE (multi-column, etc.)

By the way, last night I implemented the ||L mode, more or less as discussed above. But I'm still struggling with the control overlap (bleed-through) problem. So perhaps while working on that, I can add these other options.

Well, for what it's worth, 5.1.1189.0 is now available in beta:

http://www.microsabio.net/dist/51dev/temphold/

notes: http://www.microsabio.net/dist/51dev/temphold/ashdevnotes.txt

Aside from the auto-complete with coded-lists, it also contains an elaborate (but hopefully transparent) fix for the "bleed-through" problem. (Internally it resembles an attempt to avoid cross-town traffic by driving the other way around the Earth, but it doesn't require any application changes, which my first 5 or 6 attempts all did require.)

As for Jorge's two scenarios discussed above, after further consideration, the first one (using auto-complete merely as a fancy timer/exit trigger) doesn't require any A-Shell enhancements. Since the list/tree doesn't display until after you return from the first exitcode 30, and then only if the setdef contains a valid list specification, you are free to use the auto-complete timer for your own purposes (i.e. to allow you to do some kind of auxiliary processing or display whenever the user changes the field and then pauses for 1/2 second. However, if for some reason you allow the tree/list to display, but then want to abort during one of the auto-complete timer exits, you can easily delete the xtree/list by its new name ("xtrInfldAutoComplete")

The second scenario, I haven't really been able to get mind around. It doesn't sound hard, but it is a bit confusing to me, so if you (Jorge) or anyone else really wants it, please give me a more detailed explanation of how you might use it.