3
|
|
3 |
|
|
The LA Fox Developer Newsletter
|
|
October 1997
|
|
Automatic Combo Boxes
(Cony from page 1)
This gives us a basic dropdown list combo box. Now for the automation. Add a new property called PopupKey with a value of NoKeySet. Open up the init event for the combo box and add the following code:
PRIVATE ISource
zPopup WHERE zpuKey
=
“
+;
ALLT(This.PopupKey)
+;
“‘AND !DELETED(); ORDER BY 1 INTO; Cursor”
+
ThIs.Name
This.RowSource
=
lSource
This.Refresh
The above code sets the RecordSource for the combo box to an SQL statement that retrieves the appropriate values from the zPopup table. To use the control, simply place it on a form and set the PopupKey property to the key value in your table. This would be "Phone" or “Auto” for out example combos. It doesn’t get much simpler than that!
That takes care of populating the table, let’s let the user control the values that are in the table. My method is for the user to right-click the combo box. This opens a form that shows all the values for that combo box where the user can add, delete, and edit.
Add a new property to the combo called AllowEdit. Set the value to .T. by default. Add code to the RightClick event as follows:
IF This.AllowEdit
Do Form “zfrmPopup” WITH This.PopupKey
This.Requery
=zMsg(”o”, “Edits are not allowed on this popup.”,; “Edit Not Allowed”, “I”)
Form zfrmPopup has one grid that displays the zpuValues. I filter the grid based on the key value that is based. Make the form modal and the combo box will requery itself when you close the form. I’ll leave the actual code of the form up to you.
That’s all there is to it. You now have a combo box that allows the user to edit the values in the list and you can effortlessly add any number of combo boxes to your application.
[Ed. Note: Todd Landrum is an
independent developer. His company, Paladin Programming, writes custom software for businesses in the Denver area. He is a member of the Rocky
Mountain Foxpro User
Group.
Todd
can be reached at (303) 744-0854 orby e-mail at
paladin@ecentral.com.)
|
FoxPro’s ON ERROR command lets you replace the default error handler (‘cancel, suspend, ignore’) with your own. This feature can be a ‘hook’ for fancy error reporting programs. But an error handler doesn’t need to be a huge user-defined function (UDF) with a full user interface to be handy. In some cases, you just want to detect that an error occurred.
For example, let’s say you want to write a procedure that adds a “Suspend” bar to one of your application’s menu pop-ups. You also want to run this procedure from a hot key at any time. You can’t define a bar for a non-existent pop-up, so you’ll need to check for it first. There’s a problem, though-FoxPro doesn’t have a function to do that! Without an ISPOPUPO, how do you confirm that it’s out there? You do it with a temporary error handler, as illustrated in TMPONERR.PRG:
PRIVATE IcWasOnErr, IlPopupOk, InNewBar
lcWasOnErr
=
ON(’ERROR)
IIPopupOK
=
.T.
ON ERROR IlPopupOK
=
.F.
InNewBar
=
CNTBAR(’MYPOPUP’)
+
1
ON ERROR &lcWasOnErr
IF !m.IIPopupOK
DEFINE POPUP MYPOPUP FROM 5,5
InNewBar
=
I
ENDIF
DEFINE BAR InNewBar OF MYPOPUP; PROMPT ‘Suspend’
ON SELECTION BAR InNewBar OF MYPOPUP SUSPEND
ACTIVATE POPUP MYPOPUP
RETURN
**EOF TMPONERR.PRG**
At first glance, it looks like the code inside the IF statement would never be reached since m.IIPopupOK has to be true. The trick here is in the line with CNTBARO. If ‘MYPOPUP’ hasn’t been defined, the CNTBARO function will yield an error. If you were using the default FoxPro error handler, this would put up the usual dialog box. Instead, when CNTBARO hits the error, your temporary handler is called.
In this example, the entire “handler” is one statement, which sets a logical flag to indicate that an error occurred, then returns control to the executing procedure. The IF statement traps this and issues the DEFINE POPUP, letting the rest of the code run successfully. You could wait for the DEFINE BAR statement itself to trigger the error, but then you’d have to write loops to
|
|
Page 3
|
|
|
3 |
|