I have tried to create a popup menu to be called by a program. Apparently, menus are designed to be parts of windows, or maybe be assigned to controls to execute with the context event. There is no documentation on how to call a menu otherwise. What I want to do is:

MenuStruct=Start_Window( "MYMENU", "", "", 1 )

• Set menustruct parent name, etc., to @WINDOW.

• Set menustruct type to FLOATING

UTILITY( "CREATE", MenuStruct )

Result=Send_Event( @Window:".MENU.MYMENU", "MENU" )

• I don't see a menu here, but I want to!?

Utility( "DESTROY", @Window:".MENU.MYMENU" )

RETURN 0

After the program runs, I get a context event in window @Window, rather than a menu popup display during the program. SURELY OI can display a menu on the fly from a program?

If we understand your query correctly then no there is no such thing as a menu that is not attached to a Window in WINDOWS not only OI - by definition everything in Windows is attached to a parent and programs cannot be parents. Surely the program is running from a Window? If so consider using a Popup to present the user with choices or create the context menu with a control on the window as a parent and send a CONTEXT message when appropriate.

The Sprezzatura Group

World Leaders in all things RevSoft

As the code shows, @WINDOW provides a context for the running program. Now I want a floating menu, but NOT a context menu, to display so the user can select the appropriate action to take next.

Of course a popup window could be displayed, but is it really a part of the windows interface to use edittables in windows to let users select program options? I thought OI was going to replace this AREV interface workaround. Or maybe we should all be using Macintoshes!?

So what is the content of @Window?

The Sprezzatura Group

World Leaders in all things RevSoft

Are we drifting toward answering the original question? In AREV, I generalized the BROWSE options popup to be called as a program subroutine. When a program is started which needs a cursor select list, and no list is active, I call BROWSE to show these options.

To answer your question, @Window might therefore contain the name of the current active MDI window (if the calling program ran from its menu) or some MDI child window, or any other window which provides a "context" for the running program. What is germaine here is that the BROWSE menu is specific to this program's context, and not designed to provide "context" options to the window and its controls.

Gerald,

For a form to have query capabilities, you need to set QBFLIST property of the window during the CREATE event:

Set_Property(@window, "QBFLIST", new_list) where new_list is an @fm delimited list of keys.

The QBFNEXT, QBFFIRST, QBFPREV and QBFLAST events allow for scrolling through the list.

Sean

Only, my question has nothing to do with forms and their QBF properties. I simply wish to display a menu with user options for a program.

How do I display a floating menu within the context of a procedure or program, rather than a floating "context" menu for a form? Surely there is a way, other than reverting to the AREV-style popups? Isn't the Windows interface more advanced than that?

Gerald,

I'm not sure if you can accomplish what you want or not. To be perfectly honest, I don't understand what you are trying to do. I hear the technical request, i.e. "How do I create a floating popup menu from program without concern for a window or control?", however, the answer isn't as straightforward as one might like.

You said, "What is germaine here is that the BROWSE menu is specific to this program's context, and not designed to provide "context" options to the window and its controls."

The difficulty here is, as Sprezz mentioned, menus must have a UI parent. This can be the desktop, a window, a control, etc., but it must be a UI nonetheless. Obviously the logic to create your menu will be in a program…but isn't this program being executed (directly or indirectly) for the benefit of a running window? If so, aren't you intending to display this menu on top of this window to make its use intuitive to the end user?

I simply wish to display a menu with user options for a program.

Take by itself, this statement makes me think that you are trying to use a menu as the primary UI, ala AREV. However, I am doubting this for obvious reasons.

How do I display a floating menu within the context of a procedure or program, rather than a floating "context" menu for a form? Surely there is a way, other than reverting to the AREV-style popups? Isn't the Windows interface more advanced than that?

Without fully understanding your goal it is still hard to comment on this statement. Have you ever seen what you are describing? If so, then we know this isn't a limitation of Windows.

Can you describe how this program will be executed? What event will it fire from?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

But you should be aware that there are some limitations in this (as we've found out in the past). While in QBF mode, some of the normal window events are not processed, most notably any scripted items on the READ event which may be needed later. Sprezz has a dandy substitute for QBF which mimics most of the older AREV QBF functionality and seems to work very well.

Just a thought / reminder.

Don M.

Are asking for a menu that sits somewhere on the screen that changes as the user moves from field to field and window to window?

Are you asking for when a right click occurs, the menu always appears at a specified point?

The Sprezzatura Group

World Leaders in all Things RevSoft

I have a program MDI frame open. The MDI frame has a program main menu, with options on it. Some of those options represent "procedural" programs. One of my procedural programs, CopyCol, allows the user to perform batch changes of columnar data in the database.

When CopyCol is run from the menu, it presents a dialog box interface to get user input. However, the user input to CopyCol could also come from a command line or subroutine call, in which case there is no program-specific user interface window.

Now for obvious reasons, the CopyCol utility requires an active cursor or select list. When the command is executed without a cursor, my AREV version calls a "BROWSE" routine which displays a popup of options for producing an active cursor. What I am hoping for is that with Windoze, the funky browse popup can be converted to a "floating" menu over the MDI frame which presents the user with the browse selections.

My thinking is, in the Windows interface people are used to selecting program choices from menus, Yes? An edit table in a popup window is not really the same thing as a menu, No?

So what am I missing here? Why are other programmers asking about "going from field to field" or QBF forms? Am I being too obtuse, or too descriptive? Of course I realize that this program has an antecedent UI element, the MDI frame that started it. But the behavior of that frame should not be the issue here. My questions are simply, can a menu popup be displayed without a physical user click? Can a menu be displayed over an MDI window as part of a procedural program execution, without permanently adding it to the frame? When a floating menu is added to a UI object, why does OI assume that the menu is a context menu for the object to be displayed when the object is right-clicked?

Of course, OI documentation does not even describe this right-click context menu, and the UI interface tools do not provide for building context menus for the UI elements. But that's a separate topic.

Don,

Thanks. I can see you are really trying to understand the question. The biggest confusion is, that this menu really is program context specific and has nothing to do with any UI element which may or may not be displayed at the time the menu is required.

I have posted an additional response to the Sprezz Gods regarding the nature of one case for which a program context menu sounds like a good idea. But here is the point. Of course, a dialog box or popup window could be used to provide a user interface context to the running procedural command when a user action is required. In AREV, a popup was practically the only choice for this UI, but in Windows this interface seems awkward at best.

But now that I have read all the confusion I am causing by questioning this, maybe there is another UI design that would be more Windows-appropriate? Maybe, using a Dialog Box with radio buttons would replace the options popup?

I guess, I am asking other developers to talk about the design decisions they make when converting AREV-like UI into Windows. I am also asking, is OI letting us design the interface the "Windows" way, or just the "Revelation" way?

Gerald,

The biggest confusion is, that this menu really is program context specific and has nothing to do with any UI element which may or may not be displayed at the time the menu is required.

Based on the latest information you have posted to Sprezz and myself I would say your MDI Frame is the context, especially if the user is clicking on the MDI menu to run your program. Using AREV as an analogy, the AREV desktop (since AREV operated as a pseudo-OS) was your context. Windows apps obviously don't have that OS-like presence which makes some AREV-]OI conversion decisions difficult. Since you are using an MDI Frame (as we generally do), for the most part this is working like your application's desktop.

I have posted an additional response to the Sprezz Gods regarding the nature of one case….In AREV, a popup was practically the only choice for this UI, but in Windows this interface seems awkward at best.

I would suggest that this is not as awkward as you might think. Creating a floating menu, even if the options on that menu are expected, *is* IMHO awkward and a non-standard Windows UI.

But now that I have read all the confusion I am causing by questioning this, maybe there is another UI design that would be more Windows-appropriate? Maybe, using a Dialog Box with radio buttons would replace the options popup?

Yes, a custom dialog box or a popup would be very appropriate and work the way most Windows applications behave.

I guess, I am asking other developers to talk about the design decisions they make when converting AREV-like UI into Windows. I am also asking, is OI letting us design the interface the "Windows" way, or just the "Revelation" way?

This is slightly amusing because Revelation has been skewered for not making OpenInsight more like AREV. Revelation has repeatedly argued that OpenInsight is a *Windows* application and thus should work the way Windows works. That doesn't mean it shouldn't do anything that AREV does but we don't want to emulate AREV when it breaks conformity with normal Windows design standards.

OpenInsight is a Windows application that will allow you to pretty much design your system to work like any other Windows application. There are many of us who specialize in AREV-]OI conversions so please continue to ask your questions. If you are not that familiar with Windows or Windows UI design standards then we can recommend several good books on the subject. These have already been posted on this board before.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Gerald,

When the command is executed without a cursor, my AREV version calls a "BROWSE" routine which displays a popup of options for producing an active cursor. What I am hoping for is that with Windoze, the funky browse popup can be converted to a "floating" menu over the MDI frame which presents the user with the browse selections.

I'd be inclined to create a custom dialog box for getting this information rather than selecting from a menu. You could always add other information to this such as a progess indicator too if appropriate…

Users are used to seeing windows menus appear from a 'root' control and in response to a direct action they have taken. I imagine having a menu suddenly appear on the screen without this may be confusing and not in line with standard Windows ™ behaviour.

However, to answer your questions specifically:

My questions are simply, can a menu popup be displayed without a physical user click?

If you send the appropriate windows message(s) to it then possibly yes. A 'floating menu' in OI *has* to be linked to a parent control, be it a window or a control on a window. So sending something like the right-mouse click messages to the parent MAY trigger the menu to appear (can't say I've tested this). There is no intrinsic "SHOWMENU" call that you can use. Send_Event( "MENU" ) always triggers the event code for the said menu item.

You could also code this at the Windows API level with the USER32 Menu calls like CreateMenu, AddMenu, TrackPopupMenu etc etc, or perhaps use a 3rd party OCX control?

Can a menu be displayed over an MDI window as part of a procedural program execution, without permanently adding it to the frame?

It could be created as a child of the window, executed (see above) and destroyed, but it still needs that parent link for it's lifetime.

When a floating menu is added to a UI object, why does OI assume that the menu is a context menu for the object to be displayed when the object is right-clicked?

Because that's the way it was designed :) The OI floating menus *are* context menus. They were never meant to be anything else.

Of course, OI documentation does not even describe this right-click context menu, and the UI interface tools do not provide for building context menus for the UI elements.

Unfortunately the result of a several years of OI development neglect under previous Revelation management, and something that has been totally reversed by Mike and the team (including Ira who's responsible for the incredibly improved documentation). Yes, there are still many areas to cover, but it *is* happening … Rome wasn't built in a day :)

The Sprezzatura Group

World leaders in all things RevSoft

Sprezz,

Thank you guys much for the input. If a floating menu is NOT a good Windows(TM) item, then of course I wouldn't want to use that approach. Now, I am experimenting with a dialog box form with grouped radio buttons and a cancel button. This provides the user with a modal single-click input, and it's not too ugly (as compared to a popup with edit table).

As to "OI floating menus are context menus," I appreciate Mike and Ira's efforts to document this stuff. I notice special-cased behavior in many controls, and there is nowhere near enough documentation yet to explain it all. Ira is the perfect candidate for documentation since it is as new to him as it is to me. (In other words, he is still bothered by inconsistencies.)

You mention that a floating menu could be created and then destroyed. My reading and experimentation on this point shows that menus can only be created, not destroyed. The combination of right-click context and never destroyed makes it a very bad idea to add a menu to an MDI frame. Oh, well.

I really appreciate the input.

Gerald

Thanks, Don.

Your input is entirely taken as constructive. The "Revelation interface" versus "Windows interface" is a big issue for the AREV community like me. I want to believe that OI is an answer, while I struggle to achieve the same functionality in programming that I took for granted in AREV. (Well, I DID spend 10 years extending AREV to do what I wanted.)

My biggest challenge is to find Windows-compatible approaches when bringing my AREV functionality to OI. You guys who have travelled this path already have my unmitigated appreciation.

Gerald

I am assuming that you have some tried and true generic processes which you wish to bring to OI.

These generic processes are written in the process model of arev, not the object model of OI and so they seem not to fit very well functionally.

If that is correct, then you are not alone. I had a look at OI for a while, and found ways around many of the problems. But they were not easy. In fact i would say that it would be impossible for someone who did not already have a very good understanding of a very mature set of system conversion tools.

I made one of the aims to continue with the process model, because i believe it to be far better than the object model. So i wrapped a lot of the objects in process.

I had things like MSG calls, POPUPS, data access, done in a system conversion process, which worked in OI, generating windows from arev windows.

I was getting a bit disgruntled, like you. It appeared that OI had missed the point of Arev and Pick entirely - it appeared that the writers were trying to produce a windows environment which ran arev, rather than an arev environment which ran windows. I had, have always seen arev as the perfect process server. It appeared to me that OI had been a conversion of arev written by windows programmers.

But then i had a look at HTML and CSS, now XML also, and decided that arev and a good web interface were all that was needed.

Peter,

Thanks for the comments. I posted this because the question had been asked multiple times in the discussions over the years, without being answered. Rumor has it that soon the documentation really will address this stuff, however.

As far as AREV versus OI, I see AREV as being able to recurse in BASIC, While OI cannot (Anyone, please correct me if I am wrong here). Therefore AREV could handle cursors reliably at multiple levels with multiple windows (one at a time, of course), while OI seems to have forgotten about cursors. AREV had an editor which could work with cursors. Etc. We've gone from recursive BASIC in a single-threaded environment to single-threaded BASIC+ in a reentrant environment.

But Windoze itself is part of the problem. Admittedly, what I wanted to do with a menu is modal. In the Macintosh world, a modal dialog would be required, and the user would understand from the appearance of the dialog that a modal action was in progress. Windoze and OI seem to think that forms can be modal or not, and the interface does not need to identify modality to the user. This makes Windoze into a Pretty, Bad, imitation of a graphical interface.

I'm all for making my program over as a real Windoze application, but there are plenty of AREV things which do not need to be flushed down the pipes in the process. And there are plenty of process and interface issues which need to be done better in the conversion, too.

Gerald

You raise some interesting points, many of which are really too late to change, but here's my take on some of the issues you bring up.

As much as I talk about how PERFORM SELECT and Basic+ selects are actually the same, there is one small difference that I never really delve into, mostly because it's archane and overly technical, and really had little to do with the topics at hand. However, since you've brought it up, I suppose it's time to brush off the dust and talk about some cursor logic.

All select logic does go through the same code, so it is still true that PERFORM SELECT calls eventually call the Select opcode. Additionally, PERFORM SELECT calls automatically resolve the select list for you. That's been the basic differences as far as everyone was concerned.

There is one other difference, and that's crucial to the discussion here. PERFORM SELECT calls use a different set of variables than the Select opcode.

Cursor reduction in Basic+ reqiures 12 variables to maintain all the status information. This, as most of us are aware, are stored in the @CURSORS variable. @CURSORS is dimmensioned 8,12 giving us 9 cursors, 0 through 8.

It's generally assumed by most people that Cursor 0, while considered special by the system, sits in the 0 element of the array. It does not. Cursor 0 sits in a series of 12 global variables. The 0 element is never actually used.

The reason for this duplicity is simple, backwards compatibility. Rev G and ARev 1.0 use the 12 variables. It wasn't until multiple cursors came out that the @CURSOR variable was created.

This creates some interesting possibilities. Cursors 1 through 8 are global. They don't clear or change as you moved through TCL levels. Cursor 0, on the other hand, was saved and stored off. This was accomplished through the callable programs PUSH.SELECT and POP.SELECT, which were originally documented in the System Subroutine Manual back in 1990 or so. The EXECUTE function, called these routines to ensure that multiple levels had their own variable information.

While all of this was happening, it was still the information in Cursor 0 that was saved, so Cursors 1 through 8 were still global and available, forever unchanging as the system moved from level to level.

With the history out of the way, we now find ourselves looking at OpenInsight, and wondering how to reconcile the past with the present.

In order to acheive that multiple level of hierarchy, we need to decide what is a TCL level in OpenInsight. Is it a window? But that's not really a level, at least in my opinion. Granted a window has items linked directly to it, @RECORD, @ID and so forth, but they are static, or reasonably so. An active cursor is, well, active, and is not somthing that's bound to a window, but something that can be used by a window.

The only way to really PUSH a level up is to create a modal window, because that assumes that nothing else will happen whilst that window processes. Assuming it's a system modal window or even an application modal window. It is possible to create a modal window, then move to other aspects of the system if the modal window is only modal to the parent window.

With all that in mind, there is not an easy way to define when a new level starts and stops, and what to hook items up to.

That doesn't mean that the developer is out of luck. The developer still has access to all 8 global select cursors and one recursive cursor. When the time comes for an OpenInsight equivelent of EXECUTE, then the developer simply needs to call PUSH.SELECT to save off cursor 0 and it's state. When the EXECUTE program finishes, which presumably would return back to the original program, then a POP.SELECT brings the system back to it's original state.

OpenInsight was never meant to be an Operating Environment like ARev was. The product is not ARev For Windows. It was meant to be a Windows developent tool utilising the and enhanced R/BASIC language and the Linear Hash filing system. OpenInsight is actually more powerful than ARev, once the developer stops trying to make it work and run exactly like ARev.

As for the appearance of modality, it's not Revelation's place to define the interface for Microsoft. The whizkids at Redmond and their user interface gurus have determined the standards and appearance of modal windows. If we wish to have modal windows appear in a different colour or font, we need to code this ourselves. Keep in mind, the users expect certain things from Windows applications, whether or not we as developers agree with those expectations. Changing what is expected, by having menus serve the place of windows, or interfering with colour schemes will make your app cumbersome and irriating to the end user.

The Sprezzatura Group

World Leaders in all Things RevSoft

Sprezz ..

A very good answer and one that I've been pondering for a bit. One of the things that sometimes seems to cause trouble is the apparent loss of an active cursor's contents and, worse, the overwriting of a cursor when the select list is too long. I'm still not exactly sure how to prevent this except to do an explicit save of the cursor contents and then retrieve it when it's needed. Is this right??

Don M.

"I posted this because the question had been asked multiple times in the discussions over the years, without being answered"

I cant think of the words to get the point across. The things they could have done in keeping the good parts of arev, for want of a better term, they still could do. But there is an apparent difference of perspective which makes it difficult to see, perhaps, the benefit?

Anyway i cant think of any more words to use, so i thought i would post the source code of the program which i started writing to do the changes for me - to allow me to continue in Oi with the minimal change. Not because i am lazy. Because there are many arev systems already running which would be quite successful in a windows representation.

This source code converts source code in Arev to source code in OI. It changes what it can.

I hope that the technical people who like the direction that OI has taken can take a good look at this and see if they have done as much as they could to smooth this revolutionary path into an evolutionary path. I personally find it ridiculous that an individual would find it a useful thing to do for a couple of systems, yet the people who wrote it cant find a way to justify it either on cost or on quality grounds.

http://patlynch.homelinux.org/convcode.htm

Y'know Don that's a good point. Chatting to RevSoft it seems that a fix for this has made it into 7.0. Perhaps some gentle pressure might result in a patch while we're waiting?

The Sprezzatura Group

World Leaders in all things RevSoft

Gerald,

Back to your original issue - a context-aware floating 'menu'. One possibility is an 'allways on top' window + a variable on the parent MDI frame which stores current active child window. Thus the allways-on-top floating window can respond / change its characteristics based on whatever window is active / selected.

Now wouldn't THAT be grand!!!

Don M.

Richard,

If they had ratings on this forum, I would give that advice top marks.

Make it easier - make it a modeless dialog box (see CREATE_DIALOG) on the create event of the MDI frame and on the activated event of the mdichild set the "functions" of the modeless dialog box. Tested and working here.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprez: Yep, thats what I did with a 'hot keys' floating toolbar, just hadnt looked a the old code when I offered the suggestion.

Gerald: Note that the 'allways on top' for the dialogbox is achieved - if you dont already know - by putting the following in the Create event of the modeless Dialog Box

Call SetStyleEx(Win,8)

(which is easier than using the Windows API stuff I had to do originally).

Richard Bright

BrightIdeas New Zealand

Richard,

Thank you. Just in time for my first modal and always on top window.

I take the liberty of showing the source for your SetStyleEX subroutine which I found in a different posting of yours:

Subroutine SetStyleEX * subroutine SETSTYLEEX(CtrlEntID,AddStyle) declare function Get_Property, Set_Property * get the current Style Style=Get_Property(CtrlEntID,'STYLE_EX') If Style1,2_eqc "0x" then convert @lower.case to @upper.case in Style Style=iconv(Style3,99,"MX") end * add the new style Style=bitor(Style,AddStyle) OldStyle=Set_Property(CtrlEntID,'STYLE_EX',Style) Return **

- Oystein -

(I meant modeless, of course.

- Oystein - )

Sprezz,

Wow. I have programmed 13 years in AREV, producing a leading commercial application. Nowhere in Revelation's documentation is the @CURSORS variable defined. I never got that Revelations cursors are non-recursive. I just avoided cursors 1 through 8 on general principles, I guess, and I did not know that PUSH.SELECT/POP.SELECT made cursor 0 appear recursive. You know, I think I read pretty well, too. I did notice that OI's PUSH.SELECT/POP.SELECT worked only with cursor 0, which I deemed mildly irritating. Now I understand.

Your reference to "select opcode" means Basic's "Select File_Handle", statement right? You say that this is different from PERFORM SELECT. I'm guessing that the @CURSORS information about which file is used, etc. is missing in the opcode, although cursor 0 itself is still used. What about @List.Active?

So now that you have educated me, let's see if I can intuit how cursor 0 could move from recursive to reentrant. (1 through 8 cannot be used in recursion or reentrance, as PUSH/POP does not work on them.) In databound windows, the CREATE event could define 5 properties, maybe named @LISTACTIVE, @LS1, @LS2, @LS3, @LS4. When a cursor is actively browsed in a window, and the window loses focus, then PUSH.SELECT(LS1,LS2,LS3,LS4) followed by SET_PROPERTY(Window,LSVARLIST,LSVARS) should store the cursor. Remember that the @LISTACTIVE property must store variable @List_Active, too. Then a window's GOTFOCUS event would check the @LISTACTIVE property, and restore the active cursor using POP.SELECT.

I have noticed 64K limit problems in GET_PROPERTY and SET_PROPERTY when referencing lists of variables. Otherwise, this might work, Huh?

Now since you knew about @CURSORS, could PUSH.SELECT/POP.SELECT be rewritten to use the cursor number, and store cursors 1 through 8?

Gerald

Just read some threads in this topic… The part about cursors caught my interest. And more so did the wished patch before 7.0 release.

Since I have reported the problem way back in January of this year, and 4.1.3 came out in February… I don't think a patch will be done for revisions before 7.0

View this thread on the forum...