Drop Down Menu- Select It

I'm getting annoyed by this.  When I go to the registration form, I notice that all the drop down menus are already selected for you; meaning you still have to answer them to correct them, no matter if they're required or not.  Relationship Status is not required but to me it is since I'm not single and have to correct it.  Here's the image…

Dolphin RC3

A perfect example, I set up a States drop down menu and it's not required.  It's good for those people who live in USA however since it's already selected "Alabama" from the top of the menu list, they must answer it correctly but there's no way for people from a different country to "not" answer it.  I have to take it off because it's useless.  How come we don't see "Select it" as a default like Dolphin 6.1.6 anymore? Is there a way to get that back.  Here's the image…

Dolphin 6.1.6

I think this is important.  If a member goes to his/her edit page to edit ONE thing and then save, all the "haven't-answered" drop down menus that already selected will be saved as well without realizing it.

You are talking about drop downs created from a predefined values table - correct?  You're right, this is a problem.

Yep thats right. I seriously don't know what to do with my State drop down menu and many others.  It kinda sucks.  I hope Boonex will get that "Select it" as a default back like how it was in Dolphin 6.1.6.

If you are going to use the zip code search feature you don't really need the city or state boxes.  I don't see them rewriting the code at this point for release to have state only show up when the US is selected (which solves the issue).  The only thing you can do now is make it optional and maybe put an Other selection in the predefined fields so people outside the US can use it.

maurice - you are missing the point.  This happens for any field that uses a predefined list for a drop down.  "State" was used just as an example.

I understand mauricecano but i think you're missing the whole point here.  Suppose I set up a drop down menu for women to pick their breast size (A, B, C, D) or for people to pick how much they make a year (from $5,000 to $1,000,000). They're very personal questions and not everyone wants to answer them.   For my deaf site, I have some queries like "What is your Hearing Level" and  the drop down menu will be "Deaf, Hard of Hearing, Hearing" or "Do you know Sign Language?", the list will be "Yes, No, Not Yet".  Not everyone wants to answer these types of questions but all the drop down menus are already answered or selected so they HAVE to correct them. If they don't answer then they are defaulted as "Deaf" or "Yes".  I see that about 30% of those people on my site prefer not to say about their hearing loss or Sign Language skill which is perfectly fine and that's why they're not required.  Without a "Select it" as a default, there's a problem.

I added a blank row like this so people don't have to answer it.

But it ends up like this on profile page. It's not pretty. :(

It just doesn't make sense.  The way it worked in Dolphin 6.1.6 with "Select it" as a default made perfect sense to me and I think we should get that back.  I don't see why they threw that out.  Maybe they overlooked it.  :-/

Thanks Caltrade.  I'm glad you understand.  Yes "State" is an example :)

I do understand what your saying, but I doubt they will do anything about it until 7.1 if then.  I have a simular issue with my site and the only way around the issue I found is to make the the selector a checkbox instead of a dropdown.  By doing that they don't have to make a selection and if they don't then nothing shows up.  It only works for small list and isn't the best solution but its a solution.

@maurice - thanks for the workaround

@patrick - your site has a drop down for women to select their breast size!  Do they do that?

@CALTRADE

No i don't think so. I dunno.  I'm just pointing it out.  lol

@maurice

Thanks mauriceano, I did that trick a while ago.  I had to throw out my 4 long drop down menus. I think it's kinda serious. Oh well, back to the waiting game.  :P

If you have a large multiple select list, this is a problem.  The checkboxes are a good solution, but even in RC3 they are still in one long row - a step backwards from D6 where you could have multiple checkbox items per row.  I have tried to raise this as an issue several times, but I don't think it ever got into trac.

They were supposed to have fixed the multipule checkbox only being on one line and did not fix it.  I reposted that its still broke maybe they will get it this time.

You know this one is really a drag - they have essentially removed one of the most important features of Dolphin.   I have a search that is really important for my community.  It should allow people to search by "industries" and "trade countries" - but since the trade countries has "Afghanistan" at the top no matter what, it has made it impossible to build this search.  There is no "null" for any of the drop down searches - a major oversight that you wouldn't expect any developer to make.

The "workaround" of using checkboxes suggested by maurice is not at all practical - the list would be a mile long.   Is there even a trac on this?  Do we have to keep bouncing this thread in the hopes that Boonex eventually takes notice?

keep bouncing, there has been nothing really added to trac since the RC3 release.

I agree.  We just have to keep bouncing.  It just doesn't make sense without it.

bumping away!

And I do agree it needs to be addressed and fixed, when I posted before it fell on death ears so now with so many actively bouncing it might work!

Bump to get noticed

Do you want to take shifts on this?  I could do U.S. Pacific Standard time a few times a day.  We will probably also need someone on the East Coast of the U.S., in Europe and in Asia.

p.s. Maurice - was that a Freudian slip? - you said it "fell on death ears"

I'm EST and wasn't poking fun of patrick either, I just realized lol.

Patrick, just as a work-around, could you add another item to the drop down list, and call it (Not Specified), or something neutral.... then use it as the default answer?  Then if they didn't answer, at least it wouldn't be a wrong answer.

For instance, if you added another country and used 'None' for the value, and _Not_Specified as the language key.  The add language key     '_Not_Specified' => ''

Then use 'None' as the default country.  The First item in the drop down list for country will be blank, and that's what will be displayed if they don't select anything else.  You should be able to do the same thing with all the drop down lists that you create.

That doesn't work- I tried it - you end up searching for "not specified" so it still doesn't work.  In my case, I have two fields, "industries" and "trade countries" and want a search that should be simple to design.   If a user selects a certain country, say "Mexico" it should return all users who have Mexico as one of their trade countries, and if that is the only search in that block it does.  If a user selects a certain industry, say "Agriculture", it will also return all users who have that industry in their profile, if that is the only search in that block.  What I want though, is for people to be able to find the subset of members who are interested in Mexico and Agriculture (or Germany and Biotechnology - whatever).   When I put these two drop downs together, however, "Agriculture" is at the top of the industry drop down - fine, and "Afghanistan" is at the top of the countries field - not fine.   There is no way that I know of to "null" one of those fields.

@Boonex - the "bumping" comments are a joke, but could you weigh in on this.  This search is somewhat central to my application, and it seems a few others also.   Could we get a trac on this and if at all possible some kind of workaround.  As Patrick has pointed out, this is a major loss of functionality from D6.

No..... you won't end up with 'not specified' in the profiles, you'll end up with a blank entry..... which looks like a blank entry.

The language key  '_Not_Specified' => '' as you can see, is replaced with an empty string, and when set as the default value for the field, that's all that will appear...nothing.  A blank entry will also appear in the search drop down, which I don't think looks all that bad.  If anyone uses that field for a search, they will be essentially using nothing as a search string, and that is exactly what will be returned..... nothing.

I'm not saying it's a perfect fix, just a viable work-around until Boonex comes up with something better.

I'll try it.  If it works, that will be fine, though Boonex should fix this area.

Doesn't work on my site - though it may have nothing to do with the approach.  Generates SQL errors:

SELECT COUNT(DISTINCT IF( `Profiles`.`Couple`=0, `Profiles`.`ID`, IF( `Profiles`.`Couple`>`Profiles`.`ID`, `Profiles`.`ID`, `Profiles`.`Couple` ) )) AS "Cnt" FROM `Profiles`  WHERE ( FIND_IN_SET( 'Business', `Profiles`.`Industries` ) ) AND (  ) AND `Profiles`.`Status` = 'Active' AND (`Profiles`.`Couple`='0' OR `Profiles`.`Couple`>`Profiles`.`ID`)

Mysql error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND `Profiles`.`Status` = 'Active' AND (`Profiles`.`Couple`='0' OR `Profiles`.' at line 1

I had couples disable and tried re-enabling them - no effect, also cleared the cache.    No time now, may delve into it later tonight.

No, couldn't get this to work.  In fact, I can't seem to get two search fields to work in any search block at all.  I think this "nulling" technique did work briefly when I had it in my industry field, but before I put it in my trade countries field, but once I put it in both, it started generating the sql error message above.  Right now I have the industry search working, but the keyword search doesn't return any results at all (see: www.caltrade.com/community).  Grrrrr

Does Boonex understand this issue?  Is there even a Trac on it yet?  I had a reporter from the LA Times call me today, and I couldn't even find profiles on my own site the search is so bad.  I assume this is still an issue for others here?

Rob

I'm back.. sorry I was out for a while. Dang, I'm shocked that they haven't made a ticket for this.  Boonex, can you please tell us why this cannot be done.

Come on guys, at least acknowledge our existence!

I wrote and got a response from AndreyP on this - he says it is "normal behavior" but might put it in trac as a "feature" for  7.1.  I might have gotten them to understand it a bit more but I think we have scared them off with this long thread.  Are there any good communicators out there who can describe and sum up this issue concisely?

Rob

OK.... I tried my best

http://www.boonex.com/trac/dolphin/ticket/1627

Thank you - that is just one side of the problem though - on the join form.  The other side of the problem is when you are doing a search.  If you have set up two dropdown search fields, and just want to use one for the search, there is no way to "null" one of the forms so that just the other is used for the search.  It will have what ever value is on top of the predefined list, and thus will mess up the search.

Added a note to ticket.  You know they'll move this to 7.1

Watch me get banned from trac.  AlexT changed the status from defect to enhancement, so I changed it back.... and I'll keep doing so until somebody stops me.  The ability for a user to skip over a required field, and submit the join form without supplying any input whatsoever to that required field, is a defect where I come from.  Things like this need to work right from the very beginning.

Good,

AndreyP (Aramis) wrote me last night and again said I was requesting "a feature, not a bug", told me that  if I set things up the way they were shown in this graphic, it would be "even more universal":  http://img191.imageshack.us/img191/4589/screenshot20091211at539.png

I wrote him back and said that while I appreciated his response, this still has a value in the table, it is just not shown to users, and it will still mess up a search if there are two controls in any search block.  It will still be impossible to "null" one of the fields. I'm not all that technical, but this is so basic that it is difficult for my to understand why professional developers don't get this - especially given that it worked fine in D6.

Rob

I've explained the issue in trac well enough for them to understand that it is a problem.  The truth is, they just don't feel like working on it.  The join form is a critical issue, if you can have members signing up with wrong information.  One thing  I am sure about, if people can skip over something, you can bet they will, and being able to submit required fields without supplying any input whatsoever, will result in a lot of members with wrong information.  Odds are, once it's wrong, it'll stay wrong.  At the very minimum, this needs to be fixed on the join form, so member info will at least be accurate.  Without accurate member info, search is useless anyway.

I took a look at Andrey's suggested screenshot that Rob put up and that is NOT a solution.

How hard is it really for Boonex to add some checks to the join form.  Seriously, we have a check to ensure that the screennames & e-mails are not duplicated, why not a check to ensure the information being put into the DB on other items is also correct?

I know, Boonex is thinking, that's why they have the Mandatory Option in the Admin Panel, to make things either Mandatory or Not Mandatory, which is true, but still not a solution to this problem, especially since providing a blank LKey is just going to generate SQL Null errors as everyone here has been pointing out is happening. 

Come on Boonex, Rob gave you the error that occurs when you try to use a blank LKey, why is it so hard to add a check to the form at form generation (not at submission) that utilizes this.

Thanks, you guys. Thanks houstonlively!  I hope they will do something about it.  It sucks that I had to remove some of my good long drop-down-list questions since not all of them apply to all members.  Without "Select it" as a null is useless.  :(

mydatery put a good blog post on the topic, make sure to go comment.

MD's blog is a different issue altogether, but goes hand in hand with this one.

FYI: Aramis wrote me back and told me I should write Alex to address this issue.  I did, and got a response a few days later saying that  this is just the way the product is designed, but that "maybe" it will be addressed in some future version.  He said 7.1 would be the soonest it would even be considered.

Thanks for sharing Caltrade.  Interesting... I guess it's not that simple to fix this. :/

file PreValues.php

row 337

Delete

if( $aRow['Value'] == '' )
continue;

And no problem

:)

Not sure what your fix does or if it works Mario - haven't tried it, but I think it was more complicated than that.   This issue was resolved to my satisfaction at this link: http://www.boonex.com/unity/forums/?action=goto&my_threads=1#topic/HOWTO-create-join-form-field-with-Not-Specified-.htm