Jed Reynolds | 23 Oct 20:09 2014

Can Combo Dropdown do Mode.CONTAINS results?

I have been able to build a dropdown that shows me Mode.STARTSWITH 
results.  When the user hits enter in the combo, I get the Mode.CONTAINS 
results. I would like to see the dropdown show Mode.CONTAINS. Is there 
something else I need to do to?

TIA

Jed

---8<---
final JComboBox         search_combo   = new JComboBox();
final StrList           item_names     = new StrList();
final EventList<String> event_list     = new BasicEventList<String>();
final TextFilterator    filterator     = new TextFilterator() {
     <at> Override
    public void getFilterStrings(List baseList, Object element) {
       if (search_combo.getSelectedItem() == null)
          return;
       String search_term = 
lotrim(search_combo.getSelectedItem().toString());
       if(element instanceof StrList){
          StrList list = (StrList)element;
          for(String i : list.toArray()) {
             if (haslo(i, search_term)) {
                baseList.add(i);
             }
          }
       }
       else {
          System.out.println("element is not StrList, but: 
(Continue reading)

Rob Eden | 22 Apr 16:29 2014
Picon

CI build?

Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any
devs that want it.

Rob
Fabian Zeindl | 20 Dec 17:48 2011
Picon

Serialize SortedList

Hi,
 is there any way to serialize a SortedList, so i won't have to do the
sorting all the time? Since AbstractTableComparatorChooser is serializable…

Regards
Fabian Zeindl

--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Serialize-SortedList-tp5089414p5089414.html
Sent from the GlazedLists - Dev mailing list archive at Nabble.com.

Holger Brands | 11 Dec 11:12 2011

Re: AutoCompleteSupport

Hi Tobias,

I'll let James comment and answer your specific questions, because he is the author of this component.
Please keep in mind that AutoCompleteSupport mimics the firefox address field as it were at that time, a few years back.

Because of backward compatibility reasons I think AutoCompleteSupport will stay more or less the same.
But if you want to contribute an alternative implementation/component, we'd appreciate it a lot.
If it turns out to be stable and useful, I'd be happy to include it in GlazedLists.

Sounds good?
Other opinions out there?

Thanks,
Holger


2011/12/7 tobias.schulte <at> gliderpilot.de <tobias.schulte <at> gliderpilot.de>

Hi,

I am in the process of refactoring AutoCompleteSupport for my needs. I want to make it so, that it does not alter the editable property of the JComboBox any more but instead in readonly mode behaves more like the language selector at https://gist.github.com/. In editable mode it will behave as in non-strict mode.

I will remove strict and beepOnStrictViolation and any code handling these, because these are not necessary any more.

hidesPopupOnFocusLost is not necessary IMHO, because it is just a workaround for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100422. It just increases complexity and therefore I will drop it.

I want to drop any complexity from the editable combobox. The AutoCompletSupport wants to mimic the firefox address field. But firefox does not autocomplete, it just pops up a popup with suggestions. I think a lot of complexity can be dropped when the combobox behaves in editable mode exactly as the firefox address bar. The problem with the actual behavior is IMO with backspace. Backspace does behave strangely in non-strict mode.

What is the reason for isTableCellEditor? Why must we handle comboboxes differently when used as TableCellEditor?

What do you think about all this?

Regards,

Tobias


Picon

AutoCompleteSupport

Hi,

I am in the process of refactoring AutoCompleteSupport for my needs. I want to make it so, that it does not alter the editable property of the JComboBox any more but instead in readonly mode behaves more like the language selector at https://gist.github.com/. In editable mode it will behave as in non-strict mode.

I will remove strict and beepOnStrictViolation and any code handling these, because these are not necessary any more.

hidesPopupOnFocusLost is not necessary IMHO, because it is just a workaround for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100422. It just increases complexity and therefore I will drop it.

I want to drop any complexity from the editable combobox. The AutoCompletSupport wants to mimic the firefox address field. But firefox does not autocomplete, it just pops up a popup with suggestions. I think a lot of complexity can be dropped when the combobox behaves in editable mode exactly as the firefox address bar. The problem with the actual behavior is IMO with backspace. Backspace does behave strangely in non-strict mode.

What is the reason for isTableCellEditor? Why must we handle comboboxes differently when used as TableCellEditor?

What do you think about all this?

Regards,

Tobias

tobias.schulte | 29 Nov 14:47 2011
Picon

AutoCompleteSupport

Hi,

TextComponentMatcherEditor calls text.split("[ \t]") in refilter, when
mode == CONTAINS. 

In my opinion, AutoCompleteSupport should do the same in
applyFilter(String newFilter). 

With this changed, in non-strict mode I would be able to type "java 6"
in the AutoCompleteTestApp to find http://java.sun.com/javase/6/. 

A better case might be a dropdown box with customers (id, name,
surname, city). In a dialog you want the user to be able to select the
customer. The change would allow the user to type "name surname" or
"surname name" or "partial_id name" and find the customer.

What do you think,

Tobias

Holger Brands | 27 Nov 16:54 2011

modifying EventList from ListEventListener disallowed?

Hey guys,

just to confirm: is it true, that modifying the source list from an event listener is disallowed?
Consider the following example:
BasicEventList->SortedList->ReadonlyList

The listener on the ReadonlyList listens for an insert event and in turn deletes the first item from
the BasicEventList. While the list is of course modified, no delete event is fired:

    public void testModifyFromListener() throws Exception{
        final BasicEventList<String> unsortedList = new BasicEventList<String>();
        unsortedList.addAll(GlazedListsTests.stringToList("ABCDEFG"));
        unsortedList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": UNSORTEDLIST=" + listChanges);
            }
        });
        final SortedList<String> sortedList = SortedList.create(unsortedList);
        sortedList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": SORTEDLIST=" + listChanges);
            }
        });
       
        final EventList<String> readonlyList = GlazedLists.readOnlyList(sortedList);
        readonlyList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": READONLYLIST=" + listChanges);
                while(listChanges.next()) {                       
                    // get the current change info
                    int index = listChanges.getIndex();
                    int changeType = listChanges.getType();

                    // on insert, do a delete
                    if(changeType == ListEvent.INSERT) {
                        listChanges.getSourceList().getReadWriteLock().writeLock().lock();
                        if (listChanges.getSourceList().get(index).equals("H")) {
                            System.err.println("MODIFYING unsortedList");
                            unsortedList.remove(0); //WILL NOT BE BROADCASTED!
                        }
                        listChanges.getSourceList().getReadWriteLock().writeLock().unlock();
                    }
                }
            }
        });
        unsortedList.getReadWriteLock().writeLock().lock();
        unsortedList.add("H");
        unsortedList.getReadWriteLock().writeLock().unlock();
        Thread.sleep(5000L);
        System.err.println("UNSORTEDLIST= " + unsortedList);
    }

Is this behavoiur expected?
I guess so, but would like to confirm it. Perhaps we should document this better?

Please see http://java.net/jira/browse/GLAZEDLISTS-531 for another example.

Thanks,
Holger



Holger Brands | 29 Oct 16:55 2011

Bug in SortedList.indexOf ?

Hi all,

please have a look at
http://java.net/jira/browse/GLAZEDLISTS-528
and
http://glazedlists.1045722.n5.nabble.com/SortedList-indexOf-bug-td3421239.html

Could it be, that SortedList.indexOf misbehaves in case of mode AVOID_MOVING_ELEMENTS?

Shouldn't it read
if(mode != STRICT_SORT_ORDER || comparator == null) return super.indexOf(object);
instead of
if(mode != STRICT_SORT_ORDER || comparator == null) return source.indexOf(object);
?

Thanks for your help,
Holger


Gmane