Ah!  Yes.  Command on a mac.  Command-click de-selects.  Would you believe 
I couldn't find a single post anywhere on that?  Sometimes I think the web 
has become so cluttered with junk it's hard to formulate useful search 
terms even for google or duckduckgo.

Thanks brother.  Happy new year.  

On Saturday, January 30, 2016 at 1:51:47 PM UTC-5, Anthony wrote:
>
> De-selecting works the same as selecting multiple elements -- hold down 
> CTRL and then click the option. If you want something a little more 
> intuitive, you might look into the many available Javascript multi-select 
> widgets.
>
> Anthony
>
> On Saturday, January 30, 2016 at 12:29:50 PM UTC-5, Dave wrote:
>>
>> I was able to do some more testing and as I thought... everything works 
>> fine now that I got rid of the typo.  And without requires= it does the 
>> right thing.
>>
>> One sorta related, but not really question...  The <select multiple> box 
>> that gets created by default for that type of field... Is there any way to 
>> force it to put an option at the top for the equivalent of None?  When 
>> editing a row in the database admin under appadmin, I can't seem to 
>> deselect all.  In the real app, I will likely not allow the users to edit 
>> that, so I will be handling updates through model code... but just thought 
>> I would ask if there's an option in the Field definition I can add to force 
>> the first item in the select box to be empty/None.  It appears there isn't 
>> a way for me to un-select in the browser once something is selected.
>>
>> Thanks again Anthony.
>>
>> On Friday, January 29, 2016 at 11:15:13 AM UTC-5, Anthony wrote:
>>>
>>> On Thursday, January 28, 2016 at 11:24:16 PM UTC-5, Dave wrote:
>>>>
>>>> Actually, maybe this is a bug.   (or maybe just something that is not 
>>>> supposed to work the way I am trying to use it...)
>>>>
>>>> If I turn off lazy_table support, everything works.  I get a 
>>>> multi-select box with the file_name populated (text area that I can 
>>>> multi-select).
>>>>
>>>
>>> Actually, it is the reverse -- you get the multi-select box with 
>>> lazy_tables=True, but not with lazy_tables=False.
>>>
>>> Here is how it works. The multi-select widget is generated automatically 
>>> whenever a field has an IS_IN_DB(..., multiple=True) validator. 
>>> Furthermore, list:reference fields automatically get an IS_IN_DB validator, 
>>> but only when lazy_tables=True. The reason is that the IS_IN_DB validator 
>>> is created when the auto_validators() function is called, and that function 
>>> only assigns validators to reference fields if the referenced table name is 
>>> in db.tables. Here is the order of operations in each case:
>>>
>>> lazy_tables=True:
>>>
>>>    1. At the end of db.define_table(), the new "tablename" is added to 
>>>    db.tables.
>>>    2. Sometime later, when db.tablename is accessed, the table is fully 
>>>    defined via db.lazy_define_table.
>>>    3. db.lazy_define_table calls auto_validators, which adds the 
>>>    IS_IN_DB validator because "tablename" is in db.tables (see #1).
>>>
>>> lazy_tables=False:
>>>
>>>    1. Before the end of db.define_table(), db.lazy_define_table is 
>>>    called (prior to the new "tablename" being added to db.tables).
>>>    2. db.lazy_define_table calls auto_validators, which does *not* add 
>>>    the IS_IN_DB validator because "tablename" is *not *yet in db.tables 
>>>    (see #1).
>>>    3. The new "tablename" is added to db.tables *after* 
>>>    db.lazy_define_table and auto_validators have already run.
>>>    
>>> I'm not sure I would call it a bug, but I think we may be able to adjust 
>>> the code to make it work in either case (possibly by simply adding the new 
>>> tablename to db.tables *before* db.lazy_define_table is called within 
>>> db.define_table -- though I'm not sure if that will introduce some other 
>>> problem).
>>>
>>> Maybe open a Github issue and link to this thread.
>>>
>>> If you do not want to use lazy tables, there is a simple workaround -- 
>>> just explicitly define the validator yourself:
>>>
>>> Field('children', 'list:reference file_entry',
>>>       requires=IS_IN_DB(db, 'file_entry.id', '%(file_name)s', multiple=
>>> True))
>>>
>>> It appears you tried to do that, but you did not use the keyword 
>>> argument "requires" and instead passed the validator as the third 
>>> positional argument (which is actually the "length" argument).
>>>
>>> Note, the same issue exists with the default "represent" attribute of 
>>> the list:reference field -- you will need to use lazy tables or otherwise 
>>> explicitly specify that attribute as well.
>>>
>>> Anthony
>>>
>>>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to