I have a really weird issue that affects only a few users...
I have an ASP.NET site with an AJAX Control Toolkit combobox. When these users try typing in the combobox, the first character they type is often not recognized. They often need to hit the key twice to get it to register.
At first I thought this was an issue with their keyboards, so I had one of the users try on my keyboard. She was able to duplicate the behavior. However, when I try, it's usually fine. (I've only been able to successfully duplicate this once)
Is this a keyboard issue, or is there something else I can look at? The standard browser here is IE9.
EDIT
I've been able to reliably duplicate the "problem"...
When a user engages the dropdownlist and then starts typing, the first keystroke sets focus back in the textbox. This creates the illusion that the first keystroke didn't register. I hate to say it, but this appears to be by design. Any thoughts?
Related
I am using two tabs in my page like the attached image.
.
Here, after selecting the value in all dropdownlist controls then, i click the generate button. so, the tab is moved from parameter to report. Then again i click the parameter tab. At this time all my dropdown controls shows null value.
but I want all the dropdown values which i selected before.
how can i get the dropdown control values?
It's important to remember that web pages like this are stateless. One request won't remember anything about another request.
So in your situation, you're putting in data, then it sounds like you're clicking a link (or button) that redirects you to another page, then you try and go back to the first one, and it has to fire off yet another request, with no knowledge of the first one's state.
Given that, it seems like you have two primary options (and dozens of others that I won't bother mentioning):
Move the tabs to be on the same page. (My recommendation)
There are lots of controls out there, or you could easily write one yourself, that don't separate tab pages via multiple requests. If you did that, switching tabs wouldn't lose the data.
Add a "save" button, and disable the other tab.
This way, the user actively has to save the data before being able to leave the page via another tab. The biggest issue here comes in the form of usability.
Which one of those you choose is dependent on a number of factors, not the least of which being code maintainability and the size of requests.
I have two controls of interest on a page: a DropDownList and a Button. If the user presses the button, he gets a popup form which, when completed, causes the base page to completely reload, losing the value in the DropDownList. To clarify, it's a refresh, not a postback. I cannot change it to make it a postback. What is the most straightforward way of persisting the selected value in the DropDownList across this page refresh? I cannot avoid the page refresh, because the data entered in the popup is reflected elsewhere on the base page.
Update
I've cobbled together a tenative solution that I'm not terribly happy with: when the user clicks the button, I use javascript to get the current value of the dropdown and pass that with the querystring to the popup being loaded. When the user clicks "Save" on the popup, which causes the data to be saved then the base page to be reloaded, I first store the querystring value into a Session variable. The base page, on loading, looks at said Session variable. If a value is present, it sets the value of the dropdown accordingly and deletes the Session variable.
Although somewhat kludgy, it's the best I can come up with. I know that my Gracious Benefactors dislike using Session variables, but given the page reload, I cannot come up with an alternative. Also, since the Session variable is short-lived, being created shortly before a page is closed then being deleted shortly after the succeeding page is opened, I'm hoping this will be acceptable.
Contrasting opinions, refutating my solution or reasoning, are enthusiastically welcome.
Conclusion
Ultimately, after I described the solution to my Gracious Benefactors, we agreed upon an alternate approach: if a selection is made in the DropDownList, it must be saved before opening the popup. This avoids the whole ViewState problem altogether.
For updated question:
The solution you are trying sounds like it should work. It's not the sort of thing you want to use SessionState for but there are requirements here that make the situation out of the ordinary.
Depending on how you are getting the base page to reload you may be able to add a query string to that which would save you from putting hte value in the SessionState. But I imagine you have probably considered that.
But basically, as Postback values and viewstate are out of the question, SessionState and query strings are you only real option. Oh, unless you are allowed to use HTML5 local storage? (probably not)
From before question update:
If the aspnetForm is being posted back the the value should be persisted automatically by means of the postback values. So the first thing to know is whther your form is going through a postback or if you are refreshing the page in some other way.
If you can't postback the main form then as rockinthesixstring said an Ajax post might be what you need.
Also, if you are doing anything fancy with binding the datasource to the DropDownList or trying to persist the selectedValue yourself then check and re-think that.
I have an ASP.NET Dynamic Data web application, with an entity called ActivationResource. One of the properties of this is a CellPhone field. Now, whenever I open a List or Details view of one of these entities, the cell phone number displays for a moment then disappears.
Anyone have any ideas as to the cause of this mysterious behavior?
Strange that it would disappear after showing up. This sounds like a client issue instead of server, since the server is out of the loop after returning the page (AJAX aside).
Things to try:
If you View Source on the page, do you see the phone number after it disappears?
If you write a static HTML page with a similarly formatted phone number, do you get the same behavior?
What browser are you using, and does it happen with others?
Sometimes, browser pluggins like to mess with what they detect as phone numbers to make them do special things (e.g. I think Skype does that).
I have an asp.net page with a gridview and a couple of input text boxes and a search button.
Once I put something on both text boxes and press search, I get a result list (gridview) from a MS SQLExpress 2008 database.
Everything runs great BUT for some unknown reason the search stops working every now and then.
I type values on the two text boxes and press Search.
Instead of getting a result like always, the text on the text boxes dissapear, on the bottom says status "Done" but in fact is not displaying anything.
it gives no errors at all...it just runs...but doesn't display any data.
I have tried used several other Pc's as clients, same problem.
I have closed and restarted IE/Firefox but does't fix it.
Turning off-on the web server's pc fixes it sometimes, but of course I don't want to be doing that every 30 minutes
Any comments/ideas are appreciated
Sounds like it's giving you a redirect to GET. My guess is you're set to use Forms Authentication, and it's timing out. Try increasing the timeout, or removing authentication.
You could use Fiddler to verify that it's redirecting you.
I have user control on a ASP.NET web page, which contains a GridView and a radio button selector.
In the underlying middle tier I have a thread which goes to the database and then raises an event to say "I have some data" my User control handles this event and sets a Session Variable.
This works and I can see the event being handled and the Session variable gets the new data.
However when i go to use this session variable when the selected index of the Radio button selector changes the Session variable reports as "Nothing"
I have ensured that the obvious (i.e. spelling, Sessions switched on etc) are correct.
The GridView and radio button selector are encapsulated in the same Update panel.
Check that if your UpdatePanel - updatemode is set to 'Conditional'? also Child as triggers? I would first start by putting a stop in your page load, see whats happening from there. Do a search for all places where you populate that session variable and put a stop. You may be surprised, I have often found that page lifecycle gets confusing even though I thought I understood it. Alt - post some code and we can step through.
Yeah, sounds almost like a problem with order of operations or not checking for postback on a page load or something?
Like JamesM suggested, running your website in debug mode should really help identify the problem. You can bring up your watch window and set it for the Session variable you're looking for, then set breakpoints all over and check the value at each stop to divide and conquer the code.