Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 03 SEP 2000 03:26:14PM rayc@symmetryinfo.com wrote:

To all,

In the few OI apps that I have seen I typically see an EditLine with a button next to it that can be clicked to call a Popup. I now see that one can use a Combo Box (with its button) to essentially duplicate what an EditLine and Button will do (duh okay). Let me ask this question:

Is there anything wrong, incorrect, or ill-mannered with using the Combo Box for this? One advantage of using the Combo Box is that you can save on the number of controls (button is built in)in the form since we are limited to 115 controls.

Any wise or unwise comments are welcome.

Hope all (USA and worldwide) will enjoy this Labor Day weekend.

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 03 SEP 2000 04:44PM Don Bakke wrote:

Ray,

To be honest, I have seen where people have used a combobox in this way but never understood the rationale. I would have thought that the dropdown list would still appear anyway thereby destroying the look and feel. Since I haven't tried this (yet) I am not sure how well it works.

Since most of our apps are MDI and we have a dedicated "options" button in the toolbar (as you already know) we don't worry about this that much. There are some controls where we do add a button to the right of the control for things like calendar lookups. In these situations we use a graphic on the button that is appropriate. This alone would prevent a combobox from being used (unless you are Carl Pates and know how to tinker with these kinds of things ;-)

The other caveat is that your combobox must be edittable. Otherwise you will constantly be setting the LIST property in order for the TEXT property to permit the display of existing data.

dbakke@srpcs.com

SRP Computer Solutions, Inc.


At 03 SEP 2000 05:05PM Oystein Reigem wrote:

Don,

Just a comment about having a common "options" button in the toolbar versus a button to the right of the control: At least with the latter the user can immediately see which fields have options.

- Oystein -


At 03 SEP 2000 06:35PM JC wrote:

Using a combobox in this way has worked fine for me. A few notes though …

You need to set both LIST and TEXT (to a single data item) to change the data on return from a popup. eg

cs=control

ps=LIST'

ss=data

cs := @rm:control

ps := @rm:'TEXT'

ss := @rm:data

ans=set_property(cs,ps,ss)

A DropDown type (not simple or list) is the best option. The others have their own idiosyncracies.

Shorten the depth of the combobox so that it doesn't expand when you click the "button".

You can build a standard popup process to populate any "dropdown" that calls it, thereby simplifying your development.

Cheers

JC


At 03 SEP 2000 11:36PM Don Bakke wrote:

Oystein,

We have a promoted GOTFOCUS event that enables/disables automatically our toolbar button based on which controls have an options event. Granted, the other method tells the user which controls have options before moving their cursor. Other developers like to make their labels different (underlined or different colored) to visually identify controls with options.

dbakke@srpcs.com

SRP Computer Solutions, Inc.


At 04 SEP 2000 03:30AM Oystein Reigem wrote:

Don,

Thanks.

I have decide how to do this stuff in my new app.

- Oystein -


At 04 SEP 2000 03:52AM Oystein Reigem wrote:

Ray,

What is your question really? Using an edit line + a button + a popup – versus using a combo box - period?

I shouldn't think there's anything wrong with using a combo box. I haven't used them much, but that's more of a coincidence.

A popup is more versatile in that you can show more than one field. E.g let's say your field contains a code. A popup also allows you to show the text/explanation/full name for the code. Examples: ISO Country codes and country names; product codes and product names.

In my new app I've chosen a third way and developed my own popup window.

- Oystein -


At 04 SEP 2000 05:52AM Oystein Reigem wrote:

Don - I have to decide how to do this stuff in my new app - that's what I meant to say. So I'm grateful for your comments. - Oystein -


At 04 SEP 2000 08:53AM Don Bakke wrote:

Oystein,

Thanks for the clarification. Your second post made much more sense .

dbakke@srpcs.com

SRP Computer Solutions, Inc.


At 04 SEP 2000 09:10AM Oystein Reigem wrote:

Don,

Is one supposed to make sense the first time already? :-)

- Oystein -


At 04 SEP 2000 09:23AM Don Bakke wrote:

Oystein,

Well I suppose if my code never works the first time then I shouldn't expect any more from your posts.

dbakke@srpcs.com

SRP Computer Solutions, Inc.


At 04 SEP 2000 12:48PM rayc@symmetryinfo.com wrote:

Don,

To be honest, I have seen where people have used a combobox in this way but never understood the rationale.

With the 115 limi , I was thinking that for some developers (me included) need to sometimes take a frugal approach. In otherwords, if a ComboBox (one control) can perform the same as an EditLine Plus Button (two controls) in displaying a Popup, then why don't we see the use of more ComboBox to execute a popup via the DropDown event. My question was meant to query the developer community to see if there are any technical, design, or asthetic (sp) objections to using a ComboBox for this purpose. I played with and worked fine.

I would have thought that the dropdown list would still appear anyway thereby destroying the look and feel. Since I haven't tried this (yet) I am not sure how well it works.

Well sometimes ignorance is bliss. Without doing any special, it seems to work fine.

… we have a dedicated "options" button in the toolbar (as you already know) we don't worry about this that much.

Well I'm thinking of our "future" users. I don't know if you can make the clues too easy ;-) If we were to adapt the ComboBox approach, the user would see a button right there.

As I said before sometimes ignorance is bliss, but I'm not sure if I understand your caveat here "The other caveat is that your combobox must be edittable. Otherwise you will constantly be setting the LIST property in order for the TEXT property to permit the display of existing data.

I haven't done that much with List property therefore I'm now concern about something I don't know much about. What a party-pooper .

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 04 SEP 2000 12:54PM rayc@symmetryinfo.com wrote:

JC,

Thanks for your response. What is curious is that in my limited use of ComboBox for this purpose I have not seen the need to:

… set both LIST and TEXT (to a single data item) to change the data on return from a popup. eg cs=control ps=LIST' ss=data cs := @rm:control ps := @rm:'TEXT' ss := @rm:data ans=set_property(cs,ps,ss)

Is it possible that this might have been required in earlier versions of OI, but that in latter versions of OI, this problem was fixed?

Thanks, Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 04 SEP 2000 01:17PM rayc@symmetryinfo.com wrote:

Oystein,

What is your question really? Using an edit line + a button + a popup – versus using a combo box - period?

My questions is using a ComboBox to call a popup via the dropdown event. As you can see, the typical OI way is to use an EditLine + Button, which is two controls. Because a ComboBox has a built-in button, we have a 100 percent saving!

A popup is more versatile in that you can show more than one field. E.g let's say your field contains a code.

Yes, in my earlier experimentation with ComboBox, I thought that I could use that in place of a popup. But as you pointed out, the information displayed was unsatisfactory in that I also felt that I needed an explanation of the "selected code". Therefore, the popup was a better choice.

In my new app I've chosen a third way and developed my own popup window.

How do you develop your own popup window? And what does your popup provides that the standard OI popup does not? One thing that I find missing in the standard OI popup is that you cannot select an item by typing the row number. Do you have a fix for this?

Enough questions . Today is Labor day (National Holiday) in the USA. I think that my wife, boys, etc. and I will go see some firework along the Tennesse River: BOOMSDAY 2000: the blast that lasts!!

Cheers,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 04 SEP 2000 04:09PM Don Bakke wrote:

Ray,

JC is pointing out the same thing I was. However, if your combobox allows the user to edit the contents then you probably don't need this. Making the LIST and TEXT properties the same is a requirement for comboboxes that can only be populated by selecting an option from the drop down list.

dbakke@srpcs.com

SRP Computer Solutions, Inc.


At 05 SEP 2000 12:43AM Barry Stevens wrote:

I do this all the time. I resize the dropdown so it does not appear.

I developed a proceedure routine to call with the parameters of;

"@SELF","MYPOPUPNAME"

Clearout the retuen values stuff.

subroutine bsbs_call_popup(CtrlEntId,PopupName)

declare function popup, get_property

declare subroutine set_property

RetVal=popup(@Window,'',PopupName)

if RetVal then

set_property(CtrlEntId,"INVALUE",RetVal)
NextFocus=get_property(CtrlEntId,"NEXT")
set_property(@Window,"FOCUS",NextFocus)
Call send_event(CtrlEntId,"CHANGED")
call send_event(CtrlEntId,"LOSTFOCUS")
call send_event(NextFocus,"GOTFOCUS")	

end

RETURN 0


At 05 SEP 2000 09:45AM Oystein Reigem wrote:

Ray,

How do you develop your own popup window? And what does your popup provides that the standard OI popup does not? One thing that I find missing in the standard OI popup is that you cannot select an item by typing the row number. Do you have a fix for this?

What I don't like with the standard popup is

- It's got English texts

- It cannot handle other fonts (I need it to sometimes run a Sami font)

- It's too big when you just want to popup a few values

- It cannot show hierarchical data

and probably a few other things.

Since I do my own programming I can potentially fix anything. :-)

More details later. Perhaps.

- Oystein -


At 05 SEP 2000 12:44PM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site';return(true)]The Sprezzatura Group[/url] wrote:

For Win95/98 there's also another point to consider - Windows User Resources…

A combo box creates 3 controls, an editline, a button and a listbox, even if you aren't using the listbox, so using an editline and a button separately may help you fight the Windows resource problem that many users come across.

The Sprezzatura Group

World Leaders in all things RevSoft


At 05 SEP 2000 02:13PM rayc@symmetryinfo.com wrote:

Mr. Sprezz:

… Windows User Resources… A combo box creates 3 controls, an editline, a button and a listbox, even if you aren't using the listbox, so using an editline and a button separately may help you fight the Windows resource problem that many users come across.

Gee at first when I read this I got a little excited because my interest in using a combo box was to reduce the number of controls since we have a 115 limit in OI (bummer). My initial interpretation of your response indicate the contrary. I subsequently ran a test using a simple form containing one ComboBox and one RadioButton (with 2options). According to my count (using SYSREPOSWIN), the form has only two (2) controls. Is this correct?

Could you also please shed some light on this Window User Resource problem? What else do I have to look forward to ?

Thanks,

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 05 SEP 2000 02:20PM rayc@symmetryinfo.com wrote:

Oystein,

More details later. Perhaps.

Ahh yes, we look forward to the details .

BTW, did you modified the Popup program that came with OI?

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 05 SEP 2000 02:40PM Don Miller - C3 Inc. wrote:

Ray ..

There are 2 separate issues:

1. The OI control limit, to which you have alluded. 115 max, but things can get really unstable above 95 or so.

2. Windows 95/98 resource utilization. A combo box actually uses three lower-level windows elements, each of which requires a Windows (not OI) resource. Given the Win 3.x 16-bit environment, OI can chew up Windows resources at a fierce pace. By the way, I tend to use a Drop-Down list box with a popup a lot. It looks very snazzy if you don't extend the drop-down. In order to save resources, I'm fiddling with capturing a double-click on editlines. If options are available via a double-click, I change the background color of the control. This is pretty slick too.

Don Miller

C3 Inc.


At 05 SEP 2000 06:03PM Oystein Reigem wrote:

Ray,

I did try to modify the OI popup once. I think I succeeded with some changes and failed with others. So what I've done now is all my own window and programming.

My popup is currently a dialog box with just one control visible - to show the list of values. The popup can be started in various modes, e.g, "fixed list of values" vs "also allow new user value". In the first case I have a list box visible, in the second a combo box.

Other mode flavours are

- "show literal list" vs "show list of values from table"

- "store new user value in table" vs "don't store".

There are no visible buttons. The popup is operated with doubleclick/Enter/Esc. There's an invisible OK button ("Default Push Button") and a ditto cancel button ("Cancel Push Button"). They're just there to get doubleclicks and the Enter keystroke to work like OK and Esc like Cancel.

So far my popup works well for me. But I've only started using it in a few places yet.

Sooner or later I'll upgrade the thing with new features. But there will also be features the OI popup has got that I'll never implement. Perhaps some of them because of my limited knowledge.

There might be cases in my app were my popup will be inadequate. But for some cases I plan to use a different strategy altogether. Instead of having a data entry window pop up another window with a list, I'll let the same window change to a different mode - from a data entry mode to a list mode. More about that later. Perhaps. :-)

- Oystein -


At 05 SEP 2000 06:14PM Oystein Reigem wrote:

Ray,

In my experience - if you just have one window running you're not likely to run out of Windows resources, even if it's crammed with 115 controls. So if you need to put in one more control in a window that has run up against the 115 controls limit, surely exchanging an edit line + pushbutton for a combo box must be allowed.

But if you have several windows open you're more likely to run out of resources. Then Sprezzatura's advice seems sound.

- Oystein -


At 05 SEP 2000 06:16PM JC wrote:

This could certainly be the case. I've had a number of cases where upgrades have made some of my earlier code redundant. The trouble is, the learning curve is steep enough without having to constantly change methods due to redundancy.

I believe INVALUE will achieve the same result.


At 05 SEP 2000 06:48PM rayc@symmetryinfo.com wrote:

Don,

There are 2 separate issues: 1. The OI control limit, to which you have alluded. 115 max, but things can get really unstable above 95 or so.

Oh great. I just did a form with exactly 115 controls and I don't see how I can cut that back. It's tight. When you say unstable does that apply to the even the most recent version of OI? And what are the symptoms may I ask or should I just wait ?

…A combo box actually uses three lower-level windows elements, each of which requires a Windows (not OI) resource. Given the Win 3.x 16-bit environment, OI can chew up Windows resources at a fierce pace.

Ahh, all the more reason for a 32-bit version of OI. Do you hear that JimA or someone ?

…I tend to use a Drop-Down list box with a popup a lot.

Do you mean that you use the drop-down list to replace a popup? If so, I like the real popup because I can display the code and a description.

Mucho Thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 06 SEP 2000 12:01AM Control Limit wrote:

I have no problems with forms with greater than 95 controls. In fact I frequently exceed the 115 control limit by adding extra controls on create - and still no problems. (We run exclusively on NT which has no windows resource problems).

Another approach to the popup problem would be to create on the fly buttons next to controls that have options on the create of the form. I suggest calling a generic option handling routine from the buttons which handle all option processing including refocusing etc.. It could fall though to an index lookup (if the control say had a verifile and no set options) for instance.

Bob Watson


At 06 SEP 2000 05:12AM Oystein Reigem wrote:

Don,

Tell you what - I once made a function that worked the first time!

- Oystein -

(PS. I thought I sent this response yesterday, but there's no trace of it on the list. I must have slipped up. What irony!)


At 06 SEP 2000 05:15AM Oystein Reigem wrote:

Bob,

We run exclusively on NT which has no windows resource problems

Are you sure? I seem to recall some postings about problems with 16-bit programs (?) becoming worse on NT. (I haven't got much experience with NT, neither have most of my clients.)

- Oystein -


At 06 SEP 2000 05:27AM Oystein Reigem wrote:

Ray,

Do you mean that you use the drop-down list to replace a popup? If so, I like the real popup because I can display the code and a description

One possible solution - I don't know if it's a good one: Let the combo (or list) box be non-bound. Have your own programming populate it with a list of values containing both code and descripion. When the user selects or keys in a value, have some programming pick out the code and set the real field. To avoid having to do too much programming the easiest would be to have the real field as an invisible, bound control. (But then you get an extra control, of course.)

- Oystein -


At 06 SEP 2000 06:05AM Oystein Reigem wrote:

Ray,

I just did a form with exactly 115 controls and I don't see how I can cut that back.

I thought I made a posting once with a lot of creative/crazy suggestions for reducing the number of controls in a form. Can't find it now, though.

One suggestion was to fuse several statics for prompts into one. E.g, let's say your form contains a row of edit lines, with a prompt above each. Then you can replace all the prompt statics by one monolithic static containing all the prompt texts. You'll just have to fiddle a bit to find the appropriate amount of spaces to get each prompt aligned to its edit line. You can do something similar if you have a column of controls with a prompt static to the left of each. But it's harder to get the prompt texts aligned properly in the vertical direction, of course. (Comprende?)

One other suggestion was to replace a row of edit lines with a one-line edit table.

The ultimate suggestion is to replace SDI forms with MDI + child windows.

- Oystein -


At 06 SEP 2000 06:10AM Bob Watson wrote:

Oystein

That's not our experience with OI on NT - our app is MDI with unlimited child windows allowed and whereas we could only get 3 to 4 complex forms (50-80 controls) open in 98 we can get at least 20 open on NT without breaking.

As for other problems, we havn't any apart from maybe an occasional GPF in the datatable but I know what to avoid.

Bob


At 06 SEP 2000 07:37AM Oystein Reigem wrote:

Bob,

That's great news. If only we now could get all our clients to switch to NT… :-)

- Oystein -


At 06 SEP 2000 09:24AM rayc@symmetryinfo.com wrote:

Oystein,

One possible solution … Let the combo (or list) box be non-bound. Have your own programming populate it with a list of values containing both code and descripion… To avoid having to do too much programming the easiest would be to have the real field as an invisible, bound control. (But then you get an extra control, of course.)

You must be wearing your creative hat this morning. But at the moment, I'm trying to minimize my programming (like how do I populate a list of values. Don't forget in OI years, I'm still a "youth".) Also, that approach would go against my original intent which was to minimize the number of controls. But this ideas is worth keeping because I would like to know how to populate a List which I haven't given much thought to until you mentioned it. I will keep this in mind because I can forsee a future use for it.

I thought I made a posting once with a lot of creative/crazy suggestions for reducing the number of controls in a form. Can't find it now, though.

If you do, please pass it along should you find it. Thanks.

One suggestion was to fuse several statics for prompts into one…You'll just have to fiddle a bit to find the appropriate amount of spaces to get each prompt aligned to its edit line. You can do something similar if you have a column of controls with a prompt static to the left of each…(Comprende?)

Hey that's a real good suggestions. Thanks!

One other suggestion was to replace a row of edit lines with a one-line edit table.

I've did this already for the form with 115 controls. Without using EditTables, I couldn't have done it. It's good to know that we're thinking alike here. I don't know if you should take that as a compliment or not . Here have another beer…hick !

The ultimate suggestion is to replace SDI forms with MDI + child windows.

I may have to resort to this later for some other stuff that I will be coming across in our conversion from AREV to OI! Sofar, all my stuff have been strictly SDI.

Mange takk!

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 06 SEP 2000 09:42AM rayc@symmetryinfo.com wrote:

Bob,

That's not our experience with OI on NT - our app is MDI with unlimited child windows allowed and whereas we could only get 3 to 4 complex forms (50-80 controls) open in 98 we can get at least 20 open on NT without breaking.

That's pretty good. Are you using NT or W2k? Also, what' performance like under OI for data entry with many forms open? And if you print in OI, can you still do work in other forms? Please share your good and bad experience as I would like to know what to expect. Thanks.

As for other problems, we havn't any apart from maybe an occasional GPF in the datatable but I know what to avoid.

Hopefully these are just simple things, but if you could provide some suggestions on things to avoid, I'm sure that others (including me) would appreciate hearing them. They may be "common sense" to you, but for a neophyte like myself, any help is appreciated. Thanks again.

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 06 SEP 2000 09:51AM Oystein Reigem wrote:

Ray,

Populate combo or list box: Just set the LIST property to a @FM-delimited list of values. You might want to set the DROPDOWN property to true$. And perhaps set SELPOS to the default value (e.g, 1 if first value is default). (I see in my programming I've made a note about the TEXT property as well. Seems I once thought it might be necessary to set TEXT (to the text of the current value in the list), but I don't really think so now.)

- Oystein -


At 06 SEP 2000 01:16PM rayc@symmetryinfo.com wrote:

Oystein,

Thanks for the tip. I shall try it NOW! Hey it works ! For your information, when I set the 'TEXT' property, it stuffed the control with data. I took it out and it looks fine.

I tried separating the columns within a row with @vm: However, I see the 'strange Y', which I believe is the symbol for a @vm. For example, my simple play code is as follows:

for i=1 to 5

 1) val[i]=i:@vm:i ;* shows 'y'
    OR
 2) val[i]=i:'|':i ;* displays properly

next i

Assuming I get this to work, let's say I click on the third item in the LIST, do you know how I determine which item (1st, 2nd, 3rd, etc) was "selected" so that I can access that ROW and stuff only the first part of 'val' in that control. Also, I see only the DBLCLICK event in the ComboBox. But a single click will also select the row. So what event is used to help intercept the selection of an item from a List so that I can return only the value in column one into the Combo Control.

Again, Thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 06 SEP 2000 01:45PM Oystein Reigem wrote:

Ray,

I didn't suggest you have several columns in your combo/list box. My thought was just to string together code and description with e.g a space or some other suitable visible character between. But I think you can have several columns if you want. At least in a list box. Use the tab character (char(10)) in your data. (Must be done at runtime, but that's what you do anyway.) But note that the tabs work like tabs in a word processor. Unless your "cell data" are short enough, your columns will get out of alignment.

If you're stuck I'll try help you tomorrow. In the meantime - search this site.

Which item selected: I think it's SELPOS.

Click/doubleclick: I think you can use the CHANGED event to see if the user clicked something (else).

- Oystein -


At 06 SEP 2000 04:17PM rayc@symmetryinfo.com wrote:

Oystein,

I didn't suggest you have several columns in your combo/list box.

See a little knowledge is dangerous. Without proper supervision, who know what other trouble I will get into .

My thought was just to string together code and description with e.g a space or some other suitable visible character between.

Ahh, now I understand (more or less) what I need to separate the columns. With my prejudice, I was assuming something like a @vm or something like that was used. A "space" how simple!

If you're stuck I'll try help you tomorrow. In the meantime - search this site.

Thanks for your generous offer to help. Hopefully, however, I won't get stuck. I getting better about testing things under OI . Sometimes in my struggle, I don't know if my approach is the best way. But after I get 'some problem' to work, I don't care . Of course, I have revisited "certain processes" and look for a more elegant or creative solution (from developers such as yourself and others on this website). I have done this quite a few time which slows me down, but I think that in the long-run, it will be worth it.

…I think it's SELPOS…Click/doubleclick: I think you can use the CHANGED event to see if the user clicked something (else).

Thanks again for pointing me in the right direction.

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info


At 07 SEP 2000 07:16AM Oystein Reigem wrote:

Ray,

Thanks again for pointing me in the right direction.

You're welcome!

When I said "If you're stuck I'll try help you tomorrow. In the meantime - search this site" I was thinking of list/combo boxes with columns (tabs), because I thought that was what you really wanted. But if you've got fixed lenght numeric codes you're descriptions will line up right anyway.

- Oystein -


At 07 SEP 2000 06:14PM Bob Watson wrote:

Ray

We use NT5.1, latest service pack and performance is not affected by having many forms open. When we print in OI we generally put up a message while processing the print job which prevents the user from using OI, however you can use other apps.

The GPF problem in the edittable may not be specific to NT and it only happens rarely in specific circumstances - it shoudn't affect you. Apart from that its's very stable - most of the other problems with NT seem to have been sorted out.

Bob Watson

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/b848197c071faf468525694f006ac5d2.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1