Adding items to combobox 4

[novice001]

Hello,
Can anyone please help me. I'm trying to add/remove items to combobox from the code, but can't figure out how to do that. I tried to use addString, but I don't know how to use it correctly.

comboname.listname.addString("string&quot doesn't work

I don't need to use "datasource" property, I just want to add/remove one item at a time to the combobox. It looks like easy thing, but turned out to be a problem for me :-(

Thank you

 

[footpad]

novice001,

The key to adding items to the combo box and list object field types lies in understanding the objects Paradox creates as a result of your choice. In this case, Paradox creates a field object, which holds the selected data value and a list object, which manages the items that can be selected from.

To add values manually to either of these types, you refer to properties associated with the list object, not the field object.

As an experiment, open a form containing one of these in Design mode. Select the object, open the Object Explorer, and then make sure you're viewing the Object tree (View| Object Tree or View | Both).

Click on the plus sign next to your field object and notice that a list object appears. Select it in the Object tree and notice that it has properties and methods of its own. These are what you manipulate to add items.

To illustrate, let's assume you want to populate a list object with the names of the months when the form opens and that you want this field to automatically select the current month.

To do this, select the list object (as outlined above) and then add the following code to its open() event:

method open(var eventInfo Event)
var
   aryMonths Array[] String
   siCounter SmallInt
endVar

   doDefault
   aryMonths.addLast( "January" )
   aryMonths.addLast( "February" )
   aryMonths.addLast( "March" )
   aryMonths.addLast( "April" )
   aryMonths.addLast( "May" )
   aryMonths.addLast( "June" )
   aryMonths.addLast( "July" )
   aryMonths.addLast( "August" )
   aryMonths.addLast( "September" )
   aryMonths.addLast( "October" )
   aryMonths.addLast( "November" )
   aryMonths.addLast( "December" )

   self.list.count = 0  ; clears the list.
   self.list.count = 12 ; performance trick
   for siCounter from 1 to 12
      self.list.Selection = siCounter
      self.list.Value = aryMonths[ siCounter ]
   endFor

   ; Now, select this month
   self.list.Selection = month( today() )
   container.value = self.list.Value

endMethod

Now, you'll notice that this code is self contained; it doesn't use the names of the objects involved. You can certainly name the field object and the list object. Indeed, both are good ideas if you're populating this from another event.

Once you've named the objects, use the names to refer to the list object. For example, if you wanted to populate this list from a button, you might name the field fldMonths and the list lstMonths. Having done that, you would refer to the fldMonths.lstMonths.Selection and the fldMonths.lstMonths.Value properties to read or write the items in a list.

Hope this helps...

-- Lance

 

[Langley]

Lance's example is one of the best I've seen for this sort of thing.

I have always used the datasource property, because I find it easy to maintain and manipulate using tCursors; also, it gives the users another way to 'update' their picklists. Here is an example from a Gang database I'm working on. If the user enters a gang name that is not in the picklist, he is prompted to confirm that he wants to add it to the list. If he chooses 'no' (i.e. a misspelling), he stays in the field (this is my choice, since I don't want entries that do not appear in the gangs.db table). The gang.db table can also be modified directly from a maintenance menu by the user.

Of course, the combo list is updated in it's arrive method using the dataSource procedure. What follows is in the canDepart method of the comboBox field.

var
   tc	 	tCursor
   temp 	string
   uChoice	string
endvar

temp = self.value

tc.open(":GDB:Gangs.db")

if not tc.Locate(&quot;Gang&quot;,temp) and self.value <> &quot;&quot; and self.isEdit()
	then	uChoice=MsgQuestion(&quot;Problem:&quot;,&quot;Gang name: &quot;+temp+&quot; is not in the database. Do you want to add it?&quot;)
       	switch
            case uChoice = &quot;Yes&quot;:
            	     tc.edit()
                     tc.InsertRecord()
                     tc.&quot;Gang&quot; = temp
                     tc.postRecord()
                     tc.endEdit()
                     tc.close()
                     moveto(gangStatus)
            case uChoice = &quot;No&quot;:
                     EventInfo.setErrorCode(canNotDepart)
         endswitch
endif

Mac

"There are only 10 kinds of people in this world... those who understand binary and those who don't"

langley_mckelvy@cd4.co.harris.tx.us

 

[footpad]

Mac,

Just wanted to add a thought on your otherwise excellent example.

You may have heard of "short-circuit evaluation," the feature many programming languages use to stop evaluating compund IF statements when any condition fails.

To illustrate, assume you have IF A AND B. Languages using short-circuit evaluation stop parsing this line when A is FALSE. Languages that do not use short cicuit evaluation evaluate all conditions in the statement before determining whether or not to proceed, e.g. B gets evaluated even when A is already false.

Sadly, ObjectPAL does not use short cicuit evaluation. Because of this, it's best to avoid compund IF statements for performance reasons.

In this case, something like this may be more appropriate:

if not isEdit() then ;// "auto-edit"
   self.action( dataBeginEdit )
endIf

if self.value = "" then  ;// user cleared the value
   return  
endIf

;// if we get here, then it's a new value, so verify it.
if not tc.Locate( "Gang", temp ) then
   showError()
else
   addNewGang( temp )
endIf

(OK, I cheated a bit in replacing your msgQuestion with a custom routine, but you get the idea.)

Also, your "Gang name" error would also appear if the user accidentally exited edit mode before trying to depart. (This tends to happen more as a side-effect of sloppy coding than from anything the user does.) Reworking the IF as shown above provides a bit more accurate view of the picture.

Next, I don't really see a need for SWITCH in this context. Remember that Paradox evaluates all branches of SWITCH statements. Since you'll only get "Yes" or "No" from msgQuestion, the second evaluation is really unneccessary. A simple IF will suffice here, even when uChoice = "No"

(Y'know, now that I think about it, perhaps SWITCH is better for situations where you want behavior short-circuit evaluation.)

The performance differences may seem minor for things like canDepart, however, it can really add up in cases where you have large SWITCH statements (such as keyPhysical, action, menuAction, et al) or you call custom methods. Besides, every little bit helps.

Hope this does...

-- Lance

 

[footpad]

Just wanted to let everyone know that since the question about populating lists at runtime comes up from time to time, I've just added a couple of articles to my website based on the information in this thread and related ideas. There's also a ZIP file containing sample code.

See

http://techtricks.com/paradox/poplists.php

for details; it's long, but should contain information useful to everyone.

If, on the off chance, there's a mistake or omission, please feel free to let me know via the site's Feedback link.

Hope this helps...

-- Lance