Hello,

I have two questions.

1)I have a button next to an edit line that calls a popup for this edit line.If i make the edit line required, than i can't click on the button if it is empty.I could write a program to check for required fields before i save but this seems like the form is not responsive.Any way to overcome this? How would u all usually call a popup? Any suggestion is welcome.

2)The edittable allow user to click on any cells. So if i click on any cell and start keying in data, then i might have some blank row in between.What would be a good way to control this?

3)Any way to uniquely identify the columns in the edittable?This is to prevent us having to make changes in the program when new columns are inserted.

William,

1)I have a button next to an edit line that calls a popup for this edit line.If i make the edit line required, than i can't click on the button if it is empty.I could write a program to check for required fields before i save but this seems like the form is not responsive.Any way to overcome this? How would u all usually call a popup? Any suggestion is welcome.

Option 1.) Use the IOOPTIONS property (field 10) to only enforce required fields when the record is saved rather than when tabbing off of the control.

Option 2.) Use a dropdown combobox but shrink the control so there is no actual dropdown list. Then use the DROPDOWN event to call your popup. It won't trigger the required field processing.

Option 3.) Use our OLE button control. It has a feature which allows you to embed a button in an editline control to look like a combobox. However, you can change the picture. Clicking on it will not cause the required field processing to execute.

2)The edittable allow user to click on any cells. So if i click on any cell and start keying in data, then i might have some blank row in between.What would be a good way to control this?

Simple solution to this is to capture the GOTFOCUS and POSCHANGED events and check to see if the end user is clicking or navigating where they shouldn't be. If so, then use the SELPOS property to move the cell focus where it should be or simply move the focus to another control.

3)Any way to uniquely identify the columns in the edittable?This is to prevent us having to make changes in the program when new columns are inserted.

I think I know what you are asking here. If I do then the answer is "not really". You want to identify each column in an edittable as if it were a control name so your logic won't have to be changed each time a column position is adjusted. The best I can suggest is to design logic that looks at the LABEL property to get the column headings (even if you don't display them) and use that to determine your column positions.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks for the reply Donald.

1)The option 3 sound interesting.Could you explain in more detail how to use the ole? Any documentation i can refer to?

2)Actually other than controlling the clicking, I would still want the user to be able to insert line in between and then fill it in.But if the user leaves it blank, how can i control it? Does this solution still works with this extra scenario?

3)Yup, u got me right.The LABEL solution given will work as long as the changes do not involve the changing of the label name. Eg: Stock Item to just Stock.If the edit table can consider these columns as some kind of individual control and still be bounded together then not only will the name problem be solve but the events will not need to be shared as well.eg the gotfocus will not need to identify which column it is in and then run the relevent code for it.Maybe this is a wishfull thinking.

2) When you save the information, get the table.

Loop backwards from no_rows to 1 step -1 and check for empty rows.

If the row is empty, delete it, when finished either save, or put it back on the form, so that the write event can save.

By going backwards from the end to 1, step -1, you do not miss any rows.

Colin

3) A good way to identity your columns is to control the columns as variables within a COMMON statement.

Eg

EQU TABLE1_CODE$ TO 1

EQU TABLE1_DESC$ TO 2

etc

Use the COMMON in all code and variables instead of column positions.

Adding more columns to the table require the management of the COMMON variables only, and all should fall in to place…. but not if the user can control the column positions.

Doing this would still be possible, but you would need to use dynamic array variable to arrange the positions.

Colin

1) When losing focus on the table, you could check that the focus is to the button (or other valid locations, eg close) and if not return focus and cell position to the table.

An alternative is not to have the button, but use double-click or some other action within the cell to call the popup, so that you dont have to lost focus from the table or cell.

Colin

1) When losing focus on the table, you could check that the focus is to the button (or other valid locations, eg close) and if not return focus and cell position to the table.

William said this was an editline control not an edittable. Also, if he has the "Required" checkbox selected then this solution won't work unless he also does what I suggested to do with the IOOPTIONS property.

An alternative is not to have the button, but use double-click or some other action within the cell to call the popup, so that you dont have to lost focus from the table or cell.

IMHO, I wouldn't recommend double-click since typical behavior in Windows is to select the text when doing this. End users will get confused. (But if you were assuming this was an edittable then I can see why this might be used.) If I were to suggest something along these lines then it would be to use the right-click event/context menu. However, context menus aren't obvious whereas a button next to (or embedded within) a control is.

FWIW,

dbakke@srpcs.com

SRP Computer Solutions, Inc.

William,

1)The option 3 sound interesting.Could you explain in more detail how to use the ole? Any documentation i can refer to?

For using OLE controls in general you can refer to the Programmer's Reference Guide, download and read our Using OLE in OpenInsight whitepaper, or attend David Goddard's presentation at the Revelation Conference.

Each specific OLE control must have its own documentation as well to let you know what properties, events, and methods it supports. In the case of our button control, for instance, you would do something like this in the CREATE event of your window:

Ctrl=@Window:".EDITLINE_1"

Handle=Get_Property(Ctrl, "HANDLE")

OLECtrl=@Window:".OLE_BUTTON"

Image=bmps\downarrow.bmp"

Send_Message(OLECtrl, "OLE.AddOptionButton", Handle, Ctrl, Image, "Auto")

Send_Message(Ctrl, "QUALIFY_EVENT", "ALL_OLES", 1) ; * Capture OLE events

Then in the OLE event you would do something like this:

If EventName EQ "AddOptionButton" then Send_Event(Param1, "OPTIONS")

If you want any more information specifically related to our control please email me directly.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

Agreed, yes I did think it was an edittable…oops.

Colin

William,

FWIW, when we started our conversion from AREV to OI, we "enforced" the required field option at the control level. We found this to be awkward in a windows environment. We tried the IOOPTION, but this really made the windows too slow when Saving. What we did was to create a generic function to check for required fields. This function is called during the Write Event. The benefits of this approach are: 1) it is very responsive; and 2) the users can clearly see what required fields are empty unlike the standard message with OI. We also use this approach for checking completeness of data within our Edittables.

We did this using documentation provided by Sprezzatura on the FORM structure within OI. Very useful, if you don't have this documentation, then I suggest you buy it. It's very reasonably price. We also use the OLE controls provided by SRP (Don Bakke, et al). They are very nice and will enhance your application. For example, if you plan on using TABs in your application, then it's the way to go. Also, if you don't have S/List, then get it.

If you have any questions on this, don't hesitate to ask. As you see, there are many helpful people on this forum.

Ray Chan

(3) Identifying column in edittable even if position changed …

One wants a property of the edit table which is bound to the column and won't be likely to be changed. Wouldn't the best be the field name in the COLUMN property (assuming the column is associated with data)? Almost everything else about a column might be changed.

View this thread on the Works forum...