I have a browse list in a window, with say 20 records. I view a popup of the list, with the following parameters:

Repos_Rec=Position

Repos_Rec=1

Repos_Rec=P"

Repos_Rec=VList

Repos_Rec=K"

For 2 items in the list, none of the columns in the popup display format are filled in (The popup display does not include keys from the list). The popup shows 18 items. Since the popup is type "P", it returns the position in the popup. However, this is *NOT* the position in the original list.

I need the position in the list so that I can say, "Processing record XX in a list of YY".

Gerald

Gerard,

For 2 items in the list, none of the columns in the popup display format are filled in…

And the absence of data cases the popup to drop the 2 items? I didn't know popups did that. But I can't remember having come across the situation.

I need the position in the list so that I can say, "Processing record XX in a list of YY".

Just to make sure I didn't misunderstand: In your example with 20=2 + 18 items YY is 20, right?

But does the number 20 make sense when the user only sees 18 items? Wouldn't the number 20 make more sense if the user could see all the 20 records represented in the popup? You could show the 2 "missing" ones with a special value "(no data)" or whatever. The special value must be made with the help of a symbolic. The drawback is that the user can select the "missing" items, and you might not want that.

Can one have hidden columns in a popup? Say by setting the column width to zero? If so I can think of a different alternative: Have an extra, hidden column in the popup with the numbers 1-20 (except the 2 "missing" ones), and let the popup return that hidden column's value.

To achieve this the popup can't get its data directly from the table but from a dynamic array. Before you call the popup you must have some programming that reads the relevant data from the table and prepares the array. That programming would also look for empty items and leave them out.

- Oystein -

Oystein,

Thank you for your response. The ] appears in the title of a window. The popup displays the window's browse list (a cursor, actually), so that the user can position to a new record. Now when popup returns the wrong position from the perspective of the browse list, there is no way to figure out what record to display.

In my first test of this feature, I had 330 records in the cursor and only 322 records displayed in the popup. Ugly bug. I can carefully design popups to always include the key, and this would get around the problem except when a null key is written. However, my test popup did not include the key field. So why shouldn't popup show the blank lines for the "missing" items, if they are records in a cursor?

As far as working with positional popups, read my posting on cursors. When working with cursors, you must select by position, not key value. A table-mode or cursor-based popup must show all lines, even blank lines, if the returned position is to make any sense.

Gerald

glovel@wares.cc

Gerald,

All right. So the popup is for browsing a result list, in QBF fashion, which you've mentioned in other postings.

Btw - you're touching on something I always found was (is) a great weakness with QBF. When you want to take a jump to a specific place in the result list, say to a particular person in a name-sorted list of customers, all QBF has to offer is a dialog where you specify position. Surely a popup showing a few fields would be better. Good candidates for fields to show are the fields the list is sorted on. And if the table has some very prominent field (say, the name field of an customer table) that isn't used for sorting, that field should still show.

But result lists can be very long, making the popup take a long time to fill up. There might have to be some paging-like stuff with only a chunk of the list showing, and some means to jump/scroll to a different chunk.

But back to your problem. I believed your problem was getting the numbering (position) right when some records don't show in the popup. From this last posting of yours it seems the problem is that the records don't show. Yes, I'd think with a result list you want all records in the list to show. But that can't be difficult to get around. You just have to select the right fields to show.

Say - which fields do you display in your popup? The same fields always? Or do they depend on the search criteria used? Or the sort order? Or does the user decide?

Let's say the fields to be displayed are not the same but change with circumstances. What about having a very flexible symbolic that can show any set of fields, and use that symbolic as the only field in the popup? The symbolic shows the fields in a delimited fashion. Example:

…

Bakke, Don / 65656 / White

Lovel, Gerald / 12121 / Blue

Reigem, Oystein / 34343 / Green

…

The symbolic is told which fields to use via global variables of some kind.

Am I rambling? Do I make sense? Do I say anything relevant at all?

- Oystein -

Oystein,

Actually, you are almost on an answer. Here's how my stuff works. For each file in the app, I define popups like OPT_filename and CRT_filename. I have a routine which searches the repository for the names in sequence until it finds a popup for the table.

My QBF replacement, which works with either browse keylists or cursors, has first, last, previous, next, and VIEW options. View finds a popup for whatever table is being browsed, sets options for the popup, then displays the popup with the current record highlighted in the list.

This worked fine in AREV, where popup showed all the rows. Your comment about using a generic symbolic, and sticking the column definitions into it, would almost work here, in that a null string could be inserted to fill out "blank" lines. I almost like this idea as a display improvement. But popup suppresses not just "empty" rows but also "missing" rows.

Why not ask for a fix to popup? A positional popup is no good if the number of rows shown in the popup does not match the number of rows of data passed, and in the right order.

Popup supresses rows when read fails (it should show a 'missing' message in non-key fields) and when the display fields are empty (it should show the null value from ENV_NULL_DISPLAY_STRING$). I can't think of any justification for this behavior. Search for "empty" in the popup source code to understand these problems.

Again, thanks for your input.

Gerald

Gerald,

A couple of additional comments:

(1) With the window title showing ]" wouldn't it be nice if the popup items had something similar?:

…

33 of 456 | Bakke, Don …

34 of 456 | Lovel, Gerald …

35 of 456 | Reigem, Oystein …

…

(2) In my latest app I stopped using the OI popup and program my own instead.

(3) Here is how I do browsing in my latest app: I have different forms for different tables. Each form appears in different "modes". The upper part of the form stays approximately the same, but the large, lower part changes according to mode. First there's a "data entry" mode where the form is a normal data entry form. Then there's a "search" mode with fields for filling in search criteria. After the search has been executed the form automatically changes to a "list" mode where the result list is shown in a large, two-column edit table, with each record represented with a "XX of YY" thing and an abstract from a symbolic. The user can browse the list by scrolling. From "list" mode the user can switch to "browse" mode, which is very much like QBF browsing. (The form in "browse" mode is almost identical to the one in "data entry" mode.) If the user in "browse" mode needs to jump to a different place in the result list he can switch to "list", select the wanted row, and switch back to "browse" again. So with result lists I don't really use popups - I have this "list" mode instead. (Everything is implemented with one common MDI frame and child windows for each combination of table and mode.)

- Oystein -

Oystein,

As usual, you reveal astonishing inventiveness and creativity. However, some of us have lives and businesses and therefore just need to get the job done.

Rewriting the tools which we are supposed to get with OI is not one of my objectives. Documenting discovered problems so that Revelation Software can improve the OI product is an objective, as this should benefit everyone in the community. Therefore I'm asking to get popup fixed, not to abandon it.

However, your comment about browsing multiple files in different windows is interesting. I have discovered a problem with using cursors in separate windows which will be posted in a separate topic. Maybe you will have thoughts on this, or else you will say "abandon all hope, ye who use cursors!" to paraphrase some obscure poet.

As always, I enjoy your insightful comments

Gerald

Gerald-

You do not need to send me emails copying postings in the website. I read them here.

I can easily fix this behavior, and already have in my build system. However, as I told you when we spoke during the Memphis Roadshow, I cannot tell if this fix is a good one in that it changes behavior for all users, from behavior that has been this way for ten years. We may start showing users more data than they are used to seeing, which could be disconcerting, but since it is showing what could be a problem, perhaps they should see it.

Also, I would not display the value stored in ENV_NULL_DISPLAY_STRING$ as this is not a null value, it is a read error.

I will think about putting it into the product, based upon feedback from Works members such as yourself, and other developers whose opinions I hold in high regard.

Thanks-

Mike Ruane

Gerald,

There's a lot I don't know about cursors. I liked that overview of yours and look forward to Ira's article.

I have places in my apps where my users are in danger of meeting the problem with long lists overwriting each other. I'm happy it's getting fixed in 7.0.

- Oystein -

There are many items in this reply that disturbs me.

1) I definately would be sending emails if my first attempt (this discussion board) was ignored. Actually I use the phone, although I have yet to see any results from my phone calls.

2) The ten year old problem can "easily be fixed", and it might not be fixed. Yea… I keep reading that over and over again and I keep coming up with the same frustrating thought… How many more hours do I have to waste finding and then building a workaround for similar problems.

3) That last paragraph… obiously I am reading into it way too much. I get the feeling of…

a) I don't play golf so oops that drops me down on the list.

b) I think I have fluffed up some feathers in the past so that drops me down on the list.

c) Or dont cause upset or I will be dropped down the list.

d) Don't ask stupid questions.

e) Don't even think your right answer is correct… A vote has to be taken to see if we want it to be right or even if we like you.

I still clearly remember running into the ICONV / OCONV problems. the user help says one thing and the actual execution of these functions goes and does another. What a disaster that was for me.

Or the select (cursor) problem… 8 months now… sure hope the next release has the problem fixed.

And your indexing… whew… well I will just say that 98% good is not good enough.

The selecting of data… I have heard of inconsistancies and I have actually found some myself.

I consider these, the indexing and selecting of data, to be quite critical. You can not have them be irratic or produce unexpected results.

So revision 7 is due to be out soon. I have not been informed of any fixes or changes. I did not vote on any of the critical fixes. So I guess I will be suprised and will have to find them all on my own. I really don't think that that is true for all of the developers. So I guess I will be having to fix all of my software so that it will correctly handle all the fixes in revision 7.

Why has the best database in the world grown up into just another database?

Richard-

I'm sorry that you are disturbed by this posting.

I do read every post on the website. I don't need them to be re-sent to me via email.

Your "finding and then building a workaround for similar problems" is specifically what I am woried about when I think about making such a fix. This is a not a bug in that the software is working exactly as written- when the original writers of POPUP encountered a situation where a read failed the software was not going to display anything in the popup. It is still doing all this. I can make a change - but then I affect every popup written in the last ten years. What workarounds am I stomping on? Who is relying on the existing functionality? That is the reason for my hesitation.

You're reading way too much into the third paragraph, and seems a bit insulting to me. If you'd like to discuss this more call me at 800-262-4747 and we'll talk.

Many of 7.0's features and fixes have been shown at the roadshows and user groups over the last 3-4 months, in the US, UK, and Australia. We obviously can't show every developer and user the new changes in person, so as we get closer to our planned release date (currently late September/early October) we'll be posting them in the Works section first, and then the general discussion boards.

Mike Ruane

Whilst accepting that nobody is perfect (and so there is always room for improvement) your posting seems a little harsh.

1) Posting a link asking "have you seen this" would be politer than sending the identical postings thereby implying that you believe the recipient is not reading the board.

2) Mike makes a valid point about "breaking by fixing". It is likely that the problem with indexing was introduced by our input in an attempt to resolve an ancient indexing slowdown problem. At least we have the promise of a public bug list forum for OI 7 to assist developers in their attempts NOT to reinvent the wheel.

3) I can only assume that you misread Mike's posting here. This seems a perfectly valid way of doing business - take input from people who continue to contribute to the development of the product financially (Works subscribers) and by way of a gesture of good will from those who might not be Works Subscribers but are still respected in the community. As consultants we do not buy much product. We would expect therefore that the developer of a large vertical market product would have more input into what goes on than ourselves. In fact we know there are areas of the current product that were put into there for specific clients - we are not surprised by this nor do we feel slighted. You might give all of your clients equal attention but I can assure you that we are more likely to be flexible for somebody booking a month than someone booking a day. This is just commercial commonsense.

Revelation has a policy of fixing critical bugs. Why should anybody be invited to vote on it? Obviously we don't know if you've had the opportunity to attend any meetings where OI7 is being trailed - but if you have then you will have had opportunity to input into the product already.

Anyway as the corny old saying has it - you'll catch more flies with honey than with vinegar…

FWIW

The Sprezzatura Group

World Leaders in all things RevSoft

Mike,

Your posting has clearly generated some controversy. However, I understand that you posted here rather than responding to my email privately because you are demanding transparency in input. Similarly, I planned to write this note as a private mail, but I will put it on the discussion board instead.

One of the problems developers have had with the historical Revelation Software company was a lack of transparency. Bugs were reported but not logged, not fixed, sometimes for a decade. Some organizations had a great deal of input in development, while the "little" guy like me was powerless to affect the product. Case in point: QBE in AREV. Anybody ever use this feature? Anyone request it? Meanwhile, a bug in MENUS introduced in version 3.01, which I reported, went unfixed forever.

But guys, those days are behind us now and it is TIME TO MOVE ON. As further mentioned in this thread, Revelation Software is promising a public forum for bug reports starting with version 7.0. (Well, they are promising it to Sprezzatura.) My request is simply that most development objectives, not just bugs, be put into this open, transparent type of forum. Also, there needs to be a process where Revelation Software responds to the points and issues which are presented, so that we developers know what to expect and when to expect it.

Now there are several other issues with Mike's response to my popup request, and other developer's input, which need to be addressed. Mike says that popup is performing as programmed, and therefore its behavior is not a bug. So once we program something, it can't have bugs? I agree that the behavior and the programming match, but I personally noticed several programming errors within just the TABLE subroutine of POPUP. For example, where a field specifier contains an asterisk, it is assumed that the second part of the specifier is a key part number. This is a programming error, even if no bad behavior results.

What I am saying is, this code is badly written by someone possibly not proficient in BASIC+. And, I am saying that if anyone complained about it in the past ten years, they were probably ignored. Therefore we can hardly attribute code history as a justification for not fixing bugs. Mike has to start from scratch with figuring out what constitutes bugs, what has bugs, who they affect, and accept the responsibility for making changes which may have far-reaching consequences. This is not an easy task, in my opinion, but Mike is making the effort with the right intentions.

Now regarding the specific popup error I reported: a positional call to popup has to report back the correct position relative to the passed cursor or list, not relative to the popup display. End of story. The programmer tried to accomodate this in his code by storing the original position in the return value of his popup information, only he got it wrong. He skipped rows which were not read in his position counter. The bug could be fixed without displaying the "blank" or "missing" rows (both problems exist), by simply storing the correct position in the current display (Update RetVal with the position before the read.) Or, the bug could be fixed by storing the position of every row, and displaying blank lines for "blank" rows and "missing" rows. Or maybe, show "blank" rows but not "missing" rows? Which one is the correct fix, guys?

I know what I would do here, but Mike's objectives and mine are not the same. Therefore if any developers might be affected by a fix to this problem, weigh in here. (But leave the attitude somewhere else, please.)

Gerald

glovel@wares.cc

Gerald,

Not sure that I concur - but would have to work this thru carefully.

Take for example a situation in which I have applied an mfs on a record for which this user is not privilaged to see the data. That the data does not display in the popup is critical and handled by mfs, but do I want to show a blank line drawing attention to the information suppression?

As far as the popup is conncerned, I want to identify the ordered position in the displayed data, I'm not sure that I care about the cursor.

Without intending to confuse the issue, seems that this debate is a bit like an earlier one about sorting of symbolics in popups - should it be based on internal value or external value. Depending on point of view, both positions might be right, can alternative choices be offered without destroying the backward compatability?

My point is that what - to you - might be a blindingly obvious problem that needs correction, may well be a potential threat to my system. At the risk of appearing stogy, I kind of appreciate a conservative approach to code changes.

Richard Bright

Richard,

I really do NOT understand your response. You have a list of say, 100 items. Some of them are not supposed to display in a popup, so say only 90 of them display. The user selects line 81 from the popup display, which is 86 in your original list. If popup does not return the number 86, how do you know what the user selected? When I ask popup to return the position from a list, it has to return the correct value. When working with cursors, popup has to use positions.

I see this stuff in the discussion groups, were people want to "conserve" bugs in the code. What are developers thinking of to suggest that coding bugs must be conserved? I don't get this.

I see this stuff in the discussion groups, were people want to "conserve" bugs in the code. What are developers thinking of to suggest that coding bugs must be conserved? I don't get this.

It is difficult to see that you really don't understand this - it seems a little disingenuous but just in case, it is, hopefully, simple.

From the fact that you are just asking about this it would seem that you are coming to OI a decade after others here so you don't have a code base you have already altered to fit in with anomalies from a time when a previous management were not interested in bug fixes - period. Should Rev now fix these long standing bugs it would mean that an entire developer base would have to recheck their entire software release.

You have ways of doing things that are particular to you and your application, you are, for example the only developer we know making such heavy (and interesting) use of cursors. You are therefore in the unfortunate position of being able to discover new OI bugs that nobody else has noticed in the past decade.

The Sprezzatura Group

World Leaders in all things RevSoft

Perhaps what Gerald says is: This is a positional popup. You don't use a positional popup unless you're interested in the position in a key list.

Sorry for interfering.

- Oystein -

ahh but in our experience the majority of people use positional popups against a variable passed in by the programmer where the array is fixed by the programmer and is fully populated. Hence the result can be relied upon. We can see that if working against a cursor the logic ought to report back accurately against a position in a cursor but the majority of people's applications report against select lists where the key is being returned. So if we start putting the blank lines back in what might stop working elsewhere.

FWIW we preferred the old behaviour of a *record missing* line in the popup and off the top of our heads we don't see where this might break the application - unless of course the user (being a user) PICKED one of the missing lines and our program was not currently coded to cope with a situation where what MUST be a valid key because it is coming from a popup doesn't actually exist - a possibility the curent implementation protects against. Having said that we check regardless so it probably wouldn't affect us

The Sprezzatura Group

World Leaders in all things RevSoft

Richard,

I have thought about this some more, and I am going to go on a bit longer. However, DO NOT TAKE THIS RESPONSE PERSONALLY. I am addressing mental traps we all fall into, including myself. Many persons involved in these discussion groups need to think about these issues.

Regarding popup, the documented position option and the actual program behavior are at odds. The documentation is consistent with popup's original behavior in AREV, and this is probably the programmer's intended behavior in OI. The programmer just made a mistake. This should not be impossible to admit.

Now, let's discuss Mike Ruane's dilemma. There are developers who have been with OI for a long time, and have worked with or worked around these problems. There are developers who have come to OI recently, because they can stand Mike but they couldn't work with previous management.

Mike cannot behave like the old management and have a viable product. So where problems exist in OI, Mike has to fix these problems even when it "breaks" the workarounds others are using. Meanwhile, the older developers must take a new view too. Where they have workarounds and extensions to OI, they need to be ready to fix their own problems rather than force all new developers to work around bugs.

I have heard comments about how some organizations may not want buggy OI features fixed, because they have a vested interest in their own commercial products which replace or work around these features. I haven't seen any evidence that this is true. In fact, everyone has been most helpful to me even when I am being objectionable. However, the oldtimers need to be sensitive to this perception, and be open to fixing old code or eliminating workarounds to so that newbies can get OI to perform as expected. And when I become an old hand, I hope someone new will give me this same reminder.

Gerald

Gerald, et al.,

I appreciate that this can be discussed in a calm and reasonable way. It certainly makes it easier to see both sides of the argument rather than talking past each other.

Mike cannot behave like the old management and have a viable product. So where problems exist in OI, Mike has to fix these problems even when it "breaks" the workarounds others are using. Meanwhile, the older developers must take a new view too. Where they have workarounds and extensions to OI, they need to be ready to fix their own problems rather than force all new developers to work around bugs.

There is a level of agreement and disagreement I have with this. It seems to me that other IDEs would simply fix the problem and not worry too much if pre-existing systems have workarounds that would fail to work anymore. That is, a bona-fide problem should simply be fixed. Period.

Yet I am senstive to the fact that we support dozens of applications. These fixes would result in a significant effort to make sure these systems would still work okay. And I don't think most of our clients would be that willing to cover the cost.

I have heard comments about how some organizations may not want buggy OI features fixed, because they have a vested interest in their own commercial products which replace or work around these features. I haven't seen any evidence that this is true. In fact, everyone has been most helpful to me even when I am being objectionable. However, the oldtimers need to be sensitive to this perception, and be open to fixing old code or eliminating workarounds to so that newbies can get OI to perform as expected. And when I become an old hand, I hope someone new will give me this same reminder.

I too am not aware of companies looking to protect their interests at the cost of Revelation avoiding *bug* fixes. However, there is certainly a mutual desire for Revelation to avoid *enhancements* where 3rd party solutions can be purchased…with the caveat of enhancements that might otherwise be regarded as essential functionality. Case in point would be the OIPI. When Revelation Software (under Mike's leadership of course) purchased the OIPI and included this in OpenInsight, I applauded that as the perfect gesture to fill in a significant functionality gap.

My suggestion for bridging the gap between "oldtimer worksarounds" and "newbie preferences" would be to keep the old and introduce some new. For instance, with regards to the PopUp utility Revelation could simply create a new PopUp utility that has fixes in place. It would have a new name so older applications won't break but new developers (or old ones for that matter) can simply call the new PopUp. I believe this has been done already. This seems to me an easy to way give everybody what they want and need.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks Oystein, thanks Sprezz.

Of course, this is my point. Actually, if you examine the code to POPUP, the programmer inserts the position value to return for rows while building the popup, so he can return the original value. Only, he inserts the position AFTER skipping the row, so he gets the position wrong. Therefore the returned position could be fixed without changing the display, or with changes to the display. I see both sides, but it is not my decision. (I liked AREV's popup result, and to make AREV people feel welcome with OI, I'd want to support it.)

Gerald

now i am a bit confused here about what is going on.

IF there are "records missing" when the popup attempts to retrieve the elements then that is not a popup error but an APPLICATION error. If infact the application CAN return non-existent records (even though this sounds convuluted), then maybe the list should be preprocessed before the popup is called to remove the 'bad' items.

How or why non-existent records are being passed should be looked into and something else fixed. While it would be nice to know that a record is missing when doing a popup - that should only be used as a clue during develpment that there is an application bug, or that there has been a failure somewhere else once in real use.

With regards to those that are 'restricted' due to some other security constraints, again, i would suggest that a preprocess of the list to 'clean' the list is a much clearer approach rather then showing blank lines. I wonder how many calls for support have gone out that "something is broke" when in fact the reason was internal security restricted that user from seeing the record.

Gerald,

I know the discussion has now progressed but in the light of your comments felt it appropriate to restate or re-phrase my position.

I am not in any way negative to removing coding errors and ensuring a tool or function delivers the designed, expected behaviour. However, where a modification is proposed that will materially change the delivered result - a behaviour that we have had reason to believe as 'correct behaviour', I am anxious that ALL the implications of that change are weighed up carefully - and how it may impact on installed applications. Fixing the 'problem' and as needed, clearly documenting the fix plus workround savings may be the trick. In some situations a change or extension of the behaviour which accomodates the existing and ammended behaviour may be viable, practical and a win-win solution.

I said that I had not worked thru the popup / cursor issue - as Sprez suggested - my use of popup is typically to do with returning a key value. So perhaps your mooted changes may have no impact on my applications. However I was putting my hand up as a contingency - just dont care to be buried without trace by endevours to fix code to meet other's legitimate expectations.

Richard Bright

Jay,

I will give you 2 examples where it might not be an application error when popup drops display lines.

1) When a valid key is passed to popup, but none of the display fields of the popup are filled in the source record, popup drops the line from the display and (erroneously) drops the line from its count. A security routine is one reason for such a display problem, but other mundane reasons exist as well.

2) If a user retrieves a select list as a cursor for deleting records displayed in a popup, then of course some records may have been deleted (and therefore not displayed). If popup returns the wrong position relative to the cursor, further deletes would remove wrong records.

Since my user base is well trained in using lists as cursors, even for things like deleting records, erroneous popup results are not tolerable for me. Other developers may feel differently.

Fixing popup to return correct positions in agreement with the documentation and the expected behavior in AREV is not likely to hurt anyone. Altering popup's display behavior is more controversial, but not as important to me.

As far as security programs hiding data, I would prefer that an MFS or other function would reduce the data selections BEFORE passing the list to popup. We should not depend on popup's behavior to hide records for security. But I need to stop sounding off about this, don't I?

Gerald

Gerald

The fact is other developers DO feel differently, not MAY as is evidenced by the fact that nobody else in this thread other than you has said "yes this is a problem for me".

The Docs say

"Row position.

Row numbers of selected data are returned (@VM-delimited list if multiple selections allowed)."

It seems to be doing this does it not? Which documentation suggests that it returns the absolute position within a passed cursor? It seems to clearly indicate the row numbers of the data the user has selected. Altering this to return a pointer to an internal array would only seem to be likely to confuse users.

We assume the "need to stop sounding off about this" was rhetorical? If it wasn't we can help to provide an answer

The Sprezzatura Group

World Leaders in all things RevSoft

1) When a valid key is passed to popup, but none of the display fields of the popup are filled in the source record, popup drops the line from the display and (erroneously) drops the line from its count. A security routine is one reason for such a display problem, but other mundane reasons exist as well.

Once again my position would be that this is an application error and not a problem with popup. Selecting a file based on one set of criteria and then displaying on a second can always present problems. Think of the situation where you looking at a receivables file and select everyong in a single state, and then the popup restricts the display to only those that have an outstanding balance. That element SHOULD have been part of the initial select, and not left for the popup to filter out unwanted records.

2) If a user retrieves a select list as a cursor for deleting records displayed in a popup, then of course some records may have been deleted (and therefore not displayed). If popup returns the wrong position relative to the cursor, further deletes would remove wrong records.

Since my user base is well trained in using lists as cursors, even for things like deleting records, erroneous popup results are not tolerable for me. Other developers may feel differently.

I have run into this same problem, and had to choose to either delete the row, and push everything up one OR replace the deleted record with a value that said "deleted". I agree that when doing deletes, it is nice to maintain the whole list as original formulated, but it is the application programmers responsibility to take this into account and provide the code to make sure everything looks correct.

There would seem to be another alternative, since the code for popup is provided, and that is to make a customised copy of the program and modify it to meet your specific needs. It is not that difficult, and does not take that much time. For example, you could modify the code that skips missing records so that it puts in a value that says "deleted" or "restricted" or "no values" rather then showing a blank line.

View this thread on the forum...