Does anyone have any ideas/suggestions on displaying a

"progress bar/gasguage" while doing a select on a table, then of course having it disappear when the selection is done… i.e.

bring up a progress bar

SENTENCE=SELECT TABLE WITH STATE=LA"'

CLEARSELECT

RLIST(SENTENCE,5,,,) bring down the progress bar if @reccount then do something end else me=msg(parent,,'GENERAL_ERROR',,'No records found') end I would rather be able to display a bar of some type instead of bringing up a message that states "Selecting record, Please be patient…" and then bringing down that message when the RLIST select is done… </QUOTE> —- === At 17 NOV 2003 12:26PM Victor Engel wrote: === <QUOTE>How about a paper clip that pops up and warns that there is a much more efficient way to do the same query? </QUOTE> —- === At 17 NOV 2003 12:26PM Matt Sorrell wrote: === <QUOTE>Suzanne, One way is that you could have some global common variables. One common variable would indicate if GasGauge had been initialized, say GasGaugeOn@, and another would be the number of records processed, say TableRecCount@. Then, the symbolic field in the dictionary, let's call it Progress, would increment TableRecCount@, check to see if GasGauge was initialized, and if it was, call GasGauge to update. Finally, this symbolic should always return a value of 1 (@Ans=1). This allows you to select with this as a criteria and ensure it is calculated. You would also need a third common variable that would hold the total number of records in a table, say TableTotRecCount@. This is necessary for GasGauge to be able to calculate the percentage. At the moment, I'm drawing a blank on how to determine this. Once you have this structure in place you could use the following logic, possibly. 1) Determine number of records in table and populate TableTotRecCount@. 2) Initialize GasGauge and set GasGaugeOn@ 3) Perform the select, ensuring that the symbolic is called (with Progress=1). 4) After the select, shut down GasGauge if it is on. This is rather kludgey, and I'm not sure what it would do to select performance, but it should work. One way you could improve performance is to control how often the symbolic calls GasGauge. I do this a lot in routines by using the Mod function, and only updating every 10 or 100 records. It greatly improves your loop performance. Keep in mind, your mileage may vary, and I offer no warranties (express or implied), and as always, back up your system first. HTH, msorrel@greyhound.com Greyhound Lines, Inc. </QUOTE> —- === At 17 NOV 2003 12:26PM Oystein Reigem wrote: === <QUOTE>Matt, At the moment, I'm drawing a blank on how to determine the total number of records in a table. What about the Get.RecCount function? - Oystein - </QUOTE> —- === At 17 NOV 2003 12:26PM Suzanne Middleton wrote: === <QUOTE>Victor, Maybe I do not understand..the RLIST SELECT is function of OI, so what symbolic to update a bar could I use….do you have an example? The only way we have considered doing a progress bar type of functionally is to do a "dummy" one - such as calling a dialog box that has an editline on it that runs a script on the create to do a gasguage bar going across - just so people would have something to look at - even though it is not accurate, then do the select, then bring down the dialog box…this is obviously not accurate and cannot provide any type of percentages, but it would show at least something on the screen rather than a static message… </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>Well perhaps I'd best lock myself away, and find some sort of workable solution </QUOTE> —- === At 17 NOV 2003 12:26PM Gerald Lovel wrote: === <QUOTE>Richard, You said, "And a no reply to me means it is being ignored." This comment could be taken as an attack on our leader Mike, which might not be fair. Just because Mike ignores you and me does not mean he ignores the problems we encounter and post. A social worker would tell you that complainers, dissenters and protesters are commonly dealt with by "institutionalizing" them. In the Soviet Union, we know what that meant, but here it generally means appointing them to a committee responsible for solving the problem they complain about. Only, Mike is a computer programmer instead of a social worker. This explains why he is trying to solve our problems while ignoring us personally, instead of dealing with us personally and making us responsible for solving our own problems. Now understanding the psychology or our situation, does an attack on Mike's performance seem warranted? On the other hand, Mike did offer WORKS members the opportunity to beta-test version 7.0, only we were not included. This was his opportunity to bring us into the problem-solving loop, and to engage us personally in a problem-fixing dialog. Revelation Software's lack of transparency regarding development direction is a real problem. In fact, this is a bigger issue from a business perspective than source code development itself. A lack of transparency results in unhappy customers who express paranoid ideations about Revelation's unwillingness to help them. (As if programmers needed a reason to be paranoid.) I hope I am helping with writing this, and that you and Mike can see your relationship more clearly. I, too, would like a more productive exchange of ideas about our problems with OI. But I realize that attacking Mike out of frustration is not going to achieve that end. Gerald </QUOTE> —- === At 17 NOV 2003 12:26PM Donald Bakke wrote: === <QUOTE>Gerald, On the other hand, Mike did offer WORKS members the opportunity to beta-test version 7.0, only we were not included. Do you mean you requested to beta-test but were declined? dbakke@srpcs.com SRP Computer Solutions, Inc. </QUOTE> —- === At 17 NOV 2003 12:26PM Victor Engel wrote: === <QUOTE>What about including a symbolic field (that does the status bar logic) in the select? </QUOTE> —- === At 17 NOV 2003 12:26PM Oystein Reigem wrote: === <QUOTE>Matt, One way you could improve performance is to control how often the symbolic calls GasGauge. What about having a TIMER event set the gauge? Let the symbolic do nothing more than update the global variable. Then let a TIMER event, which can run as seldom as one likes, e.g, once per second, check the global var and update the gauge. - Oystein - </QUOTE> —- === At 17 NOV 2003 12:26PM Matt Sorrell wrote: === <QUOTE>Oystein, That's a much better idea. I'm still stuck in the ARev 3.1 area, so I was just throwing out some general/theoretical ideas. Nice thing about this forum. People usually don't get their undies in a wad when someone suggests improvements to a routine, and, IMNSHO, it makes everyone a better developer. Thanks for the idea!!! msorrel@greyhound.com Greyhound Lines, Inc. </QUOTE> —- === At 17 NOV 2003 12:26PM Oystein Reigem wrote: === <QUOTE>Matt, It's a nice forum all right. Even if I sometimes abuse it a bit. Btw - funny expression that "undies in a wad" of yours. Haven't heard it before. Perhaps even funnier - I wanted to reply to your posting, and since that expression stuck in my mind I searched for "undies" to find it. I found it all right but lots and lots of other postings too. First I thought the Internet got its cables crossed but then I realized somebody made "undies" and "under" synonyms in the postings database. - Oystein - </QUOTE> —- === At 17 NOV 2003 12:26PM Gerald Lovel wrote: === <QUOTE>Don, Definitely I meant that I was not included in the beta test list. As per Bob Carten's posting, I understand that Revelation Software has reasons for this which do not include avoiding complainers. Gerald </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>Oystein, As Mr. McAuley would undoubtedly point out here, no-one does prolix like I do . Cheers, Steve </QUOTE> —- === At 17 NOV 2003 12:26PM The Sprezzatura Group wrote: === <QUOTE>So true… "Logorrhea" Smith. Now what's the opposite? The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> —- === At 17 NOV 2003 12:26PM Don Miller - C3 Inc. wrote: === <QUOTE>Ira .. I've read and used that info, too. The problem with trying it during a SELECT is that you don't have access to the counter along the way so there's no way to update the gauge. This has been a somewhat longstanding gripe about OI SELECT's ability to let the user know where the process is. Also, there's no ability to ABORT a long select that's gone wrong either .. sometimes wish for a lot AREV's functionality. I don't think there's any way to get at what's needed (at least as far as I've found). Don M. </QUOTE> —- === At 17 NOV 2003 12:26PM Richard Hunt wrote: === <QUOTE>My opinion on the… 1) Progress gague. 2) Abort ability. 3) And the major bug fixes… or should I say… bugs not fixed. Don't hold your breath. It has been 9 months with only a little interest on the above item 3. Definately no results. After the beta 7.0 disappointment towards selects… I have considered and have done major workarounds for the select and indexing routines. It sure does ease the frustration. Now… I got a bug… I fix it. No more year long waits. </QUOTE> —- === At 17 NOV 2003 12:26PM Mike Ruane wrote: === <QUOTE>Gerald- Thanks for your comments. I'm not sure if you have any background or degrees in psychology, nor if your points are valid. I would suggest that since you are not me, you do not state what I am thinking. I can tell you this, and I've stated it before on this website. When we encounter a 'bug', whether it is real, imagined, a documentation error, or behavior that a user does not want and feels should be changed, we at RTI have to decide if it is a bug, how we can fix it, what the effects of the fix are on the existing install base, and if it is a bug who it will affect and how, and so we prioritize it. We read and decide about all bugs posted here. We try to avoid the 'boy who cried "wolf" ' situation whree someone who, in your words, is a complainer, and may have actually found an actual bug, but we ignore because of the chronic 'complaining'. Part of the 7.0 release will be a bug tracking section on the website. We do what we can. We, like every other organization, have finite resources in both time, personnel, and money. We do the best we can. We always try to do better. I would suggest that if you are not happy with RTI's performance or products that you evaluate other software. I believe you've only begun to work seriously with OpenInsight in the past year or so. I, and many, many others, have been working with OpenInsight sine it was released some ten years ago. We have the experience of working with an organization that did not seem to be responsive to the user or developer's needs at many times. I think that in the last three years we have changed that perception noticably. It seems a little bothersome to me (not the exact word I mean but very close) that someone who comes to the party late and didn't go through all we did (and remember I was an OI developer than, with not official ties with RTI at all) should come in now and raise a ruckus, whether valid or not. I know that this is not the proper attitude to have, yet I feel it nonetheless. As I have stated before, we continue to make RTI and OpenInsight the best that they can be in their respective classes. I also realize that no matter what we do, some people will not be happy. I suggest to them that if our performance is not up to their standards that they vote with their feet. I have done so in the past and will continue to do so. Regarding the beta site and release access, we have plenty of testers who are giving us a wide cross-section of development and user strategies. We turned down a number of requests; it is not all about you. Mike Ruane President, Revelation Software </QUOTE> —- === At 17 NOV 2003 12:26PM Ira Krakow wrote: === <QUOTE>Suzanne, I think this Knowledge base article ("Displaying Dynamic Text Using the Progress Bar") will help. http://www.revelation.com/WEBSITE/knowledge.nsf/d77dcc92cb73ae6b852566f500657e9d/97e8dd1fdb11047185256cc6005e97fb?OpenDocument&Highlight=0,progress Ira ikrakow_1999@yahoo.com </QUOTE> —- === At 17 NOV 2003 12:26PM Matt Sorrell wrote: === <QUOTE>Wouldn't a disembodied eye be more appropriate? *grin* msorrel@greyhound.com Greyhound Lines, Inc. </QUOTE> —- === At 17 NOV 2003 12:26PM Oystein Reigem wrote: === <QUOTE>Paul, Sort of slipped my mind that the number of hits and not the total number of rows is what's relevant here (except when you select the whole table). And the number of hits can't be known until after the process is finished. But you haven't solved that problem, have you? - Oystein - </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>You guys never studied lateral thinking, did you? I'd suggest that you can measure progress in a number of ways, at worst retrieving the raw file name from the handle, getting the file sizes of LK and OV using DIR(), and getting the raw record count from the file header, then working out the average record size, and working from there. Approximation is not a crime. But then again, why is this necessary? </QUOTE> —- === At 17 NOV 2003 12:26PM Paul Rule wrote: === <QUOTE>After reading this thread with interest, I decided to revisit this idea. I'd looked at it in the past but the end result was always a bit "how are you going". This is a new attempt which may help throw some ideas around. PROGRESS_ETA is a routine of mine that displays a percentage bar on the status line. Main problem seems to be determining the number of records. Works OK with straight select, but if you put criteria in then the get.reccount function doesn't suit. So, use something like SELECT FILENAME WITH STAT=1 common /stat/num.recs@,sys1@ declare function get.reccount declare subroutine progress_eta if @reccount=1 then open "FILENAME" to filename then num.recs@=get.reccount(filename,0,0);sys1@=" end progress_eta(@reccount,num.recs,"Selecting",sys1@) @ans=1 </QUOTE> —- === At 17 NOV 2003 12:26PM Suzanne Middleton wrote: === <QUOTE>Does anyone have any ideas/suggestions on displaying a "progress bar/gasguage" while doing a select on a table, then of course having it disappear when the selection is done… i.e. bring up a progress bar SENTENCE=SELECT TABLE WITH STATE=LA"' CLEARSELECT RLIST(SENTENCE,5,,,)

bring down the progress bar

if @reccount then

 do something

end else

me=msg(parent,'','GENERAL_ERROR','','No records found')

end

I would rather be able to display a bar of some type instead of bringing up a message that states

"Selecting record, Please be patient…"

and then bringing down that message when the RLIST select is done…

Mike,

Talking only about the select list fragmenting problem… I posted on the beta discussion board on 09/26/03 04:55:39pm. As of right now… no reply. And a no reply to me means it is being ignored. I also believe that since no fix was done within the new release, it really is not a beta issue.

I do understand, and already understood, that it involves a couple of core routines, since I created my own workaround. Can you imagine how long that took me? It would have been a whole lot easier for me if I would not had to have done it myself. I would have been more than happy to work with you on beta testing it. I would have even been happy to be allowed to have my own custom version of the core routines for selects.

Like I have said before… This is a critical flaw. Others just have not run up against it. Once they do, they will have major problems.

Gerald.

Thanks for your posting. You provide a good perspective.

Your comment about the transparency of the development process struck a chord. I thought we were doing enough already. Mike's Letter from the President sets out the priorities for the year. Mike has travelled the world ( he is in Australia today ) to trade shows demonstrating the state of the product and discussing our plans for the future. The beta program is a way for us to have an inclusive development process. The primary purpose of the beta program is to shake down the new code, though. We limit the number of participants because we found that beyond a certain number of people the number of bugs discovered does not increase while the administratve cost does. Is there something else we could do to improve comfort with the transparency of our development process?

Bob

Michael ..

Bravo .. for those of us who had to work with the Dark Prince (and even work for) the light is much brighter.

*I* think you and the kids are doing a great job .. all that i wnat .. nope .. but when have you ever known me to ever be fully satisfied

Just worry about 7.0 .. keep up the great working listening .. and we will all be the better for it

of course that is just my 2cents

PS .. as an update .. since my friend Tim Marler has told me I was kissing too close to the cheeks .. I must say I really do want drag and drop .. why haven't you given me that yet?

Hello Hello Hello ..

Is there anybody in there ..

Just nod if you can hear me ..

Is there anybody home?

XOOX

dsig@sigafoos.org

DSigs Radio Free Oregon

Now why didn't I think of that!

I've had the blinkers on for too long.

I'll go and hang my head in shame.

Suzanne,

I don't think an inaccurate gas bar is a good idea, because it lies about how far the process has come. A cyclic animation would be better. E.g, think of the one that Explorer shows when you copy files, with documents that fly from one folder to another. In itself it doesn't say how far the process has come but it tells the user the system is busy working on the task. To implement an animation you need a suite of images for the visuals (you might be lucky and find something, e.g, on the net) and a couple of events with TIMER programming (which is very simple indeed).

You might also consider some text that warns that the process might take time. You can animate text too with TIMER programming, e.g, make the text cycle through

Selecting Selecting. Selecting.. Selecting…

or show as a blinking

…Working…

or something.

Another idea: If you're clever you might be able to make a rough estimate of the time the SELECT it takes from (1) the size of the table and (2) the complexity of the SELECT, and use that estimate in a message, e.g,

This might take a few seconds

vs

This might take a minute

vs

Time for coffee and a snack!!

Make it a pessimistic estimate. I think it's better to err on that side.

- Oystein -

Richard-

I don't normally comment on beta changes in the Open Discussion area, but I decided to respond to this one.

Regarding your issues:

Numbers one and two are tied into changes made to RTP12 and it's related programs when OpenInsight was first develped.

Issue number three, if it is in fact the temp record overwrite in syslists you have brought up before, has been around since the creation of OpenInsight. In that time it has been brought to our attention by perhaps two or three people, and you are one of them. The error was fairly uncommon, but was reproducible, if you had multiple selects on the same workstation by the same user that spun out into different temp lists.

Items one and two are fixable we think, now that we've been through that particular batch of code so many times. Item three has been fixed in the latest beta, we think, which should be going out today, if we fix a problem that we intorduced with OIPI.

If we make a change to items one and two, and two seems relatively easy, they'll be part of an Upgrade to the Works members, just like any other. Item one is a little more complicated in that we can't count on a device like a status bar (statup) being there, so do we send_info and hope that there is a system receiver, or do we do a gas gauge message, or something else? I don't know yet, but we'll figure out something.

Sorry if the response on your reported bugs is not fast enough. You and I talked about this on the phone about a year ago and I thought we would have the fix in 4.1.3, but it didn't happen. I understand that this is a big issue for you, but there were easy work arounds that people who encountered this problem but didn't report it must have been doing for about ten years, and correcting this meant making changes to six low-level and extremely important routines used by nearly every process in OI, and I was reluctant to make the changes lightly.

Mike Ruane

Mike,

If I perceive someone as being humorous, generous, smug, authoritarian, or defensive, that does not mean that I am psychoanalysing them. It means that I am analyzing my responses to their behavior and their statements. I assume that my perceptions are not atypical, especially when my perceptions are validated by some other observer's statements.

If I tell someone what my perceptions are and they take offense, does that say something about me, or about them? So how would you perceive your response to me?

Gerald

DSig ..

But of course (not coarse).

Don M.

Bob,

I appreciate your willingness to see my posting in a positive light. After I have thought about this a while, I promise you a detailed response regarding how I think we can contribute to more transparency in development. Or, call me for a personal discussion.

Gerald

glovel@wares.cc

800-727-4587

The size of the OV file is irrelevant unless you also know the size of the overflow free list and potentially an unknowable dumped (I don't mean dumplh here) freelist size.

Steve,

Don't you know it's mandatory to do some unnecessary stuff?

- Oystein -

If "loghorrea" is decimal, then the binary equivalent must be "diarrhoea".

Perhaps "aphasia" is close enough for an antonym. It's a dumb guess.

Gerald,

I understand that Revelation Software has reasons for this which do not include avoiding complainers.

Is that sarcasm or a confession?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

View this thread on the forum...