Perhaps I've been searching for the wrong thing but I've not been able to find a solution of how to either style or disable the default way that browsers on iOS handle <select>. I know when you're actually developing for iOS applications it's called a UIPickerView. Whenever I search for this I always get links to app development help.
Is any one aware of a way to handle this?
The problem that we are having is that our security questions, on our form, are too long to see.
Note: The screen shot is not of our site. I was just trying to provide an image of that to which I was referring.
Hello StackOverflow community,
I've just started having an issue with hyperlinks stored within an MS-Access table not behaving as expected.
I have a small database which, among other things, records links to documents hosted on a company Sharepoint site. Until a few days ago, all was working fine with both the database and the hyperlinks.
For some reason, within the last few days, whenever I (or any of my users) click on these hyperlinks through an Access form (or me clicking directly from the tables), I am getting strange behavior:
Clicking the link does open a new instance of the default browser, as desired. And that browser does navigate to the company Sharepoint site. But none of the links actually open the specific document that they are intended to point to.
Instead, all links are bringing up a general file/folder menu within the Sharepoint site. It is almost as if these links point to a non-existent file within an existing folder.
The very strange part is, if I "edit" any of the hyperlinks in my database, and simply select and copy the "address" text from within the edit hyperlink window, I will always immediately pull up the correct desired document if just paste the address directly into a new browser window.
I would have thought that this type of cutting/pasting would necessarily be equivalent to simply clicking the link. But that is obviously not the case.
I feel like I can safely rule out the possibility that any changes to the Sharepoint site itself would be causing my issue with simply clicking the links (otherwise cutting/pasting the addresses would not bring up the correct documents), but I have to admit I am simply stumped as to why just clicking the hyperlinks directly used to work, but no longer does.
I don't believe there is any code or other relevant information that might be helpful that I am neglecting to include, but would be eager to provide any clarifications/etc if anyone has any idea as to what might be happening here.
Thanks in advance for any thoughts or suggestions!
~JQN
EDIT: I had deleted this question because the issue described above had simply stopped happening. I was unable to explain why, but was also unable to reproduce the issue again after a certain point within a day or two of making the original post.
Since then, the issue has returned. I've been able determine the following:
As described in my note below, when I am getting this odd link behavior, I do NOT get the standard warning from MS-Access indicating that hyperlinks may be harmful, etc.
Strangely, simply opening up a file dialog/file picker and then navigating through that dialog to any location on the (sync'ed) Sharepoint site seems to make the problem go away. I do not need to actually select or open any location on Sharepoint, simply navigating within the sync'ed folder structure seems to do the trick.
Once this happens, all links behave as intended again (ie. they open the correct linked file directly instead of landing on the root folder page). They MS-Access hyperlink warning returns as well. The file/link behavior will remain in that state for several days. Only after, I'd estimate, a week or more of inactivity since the file dialog was last run will the issue return.
FURTHER EDIT: New update...Enough time has passed so that the issue is recurring again. As suspected, links to pages outside of Sharepoint are not affected, and open as expected without issue. Once again, the standard Microsoft hyperlink warning dialog is not coming up for any links.
Obviously, now that I've found the work-around with the file dialog, it's easy enough for me to fix the issue when it arises. I'm hoping that this rings a bell with somebody, though, and perhaps one of you could point me in the right direction for a more complete fix for my users.
Thanks again for any help with this!
YET ANOTHER EDIT: Ok....based upon all the things I've learned in the last couple of weeks (as captured in this post and the comments below), I was about to delete this question and re-post it as "Why is Sharepoint redirecting my URL requests from MS-Access?" As I tried to search the forum to make sure that that question hasnt already been asked, I stumbled across some info that I think gets at the underlying issue:
It looks like this is related to the (very opaque) way that Office processes URL requests. It apparently doesn't simply open the document at the specified link, it first "pre-tests" (I suppose that's the right word) the URL by sending a "Microsoft Office Protocol Discovery" request first.
Apparently, it is possible for Sharepoint to somehow not like the particulars of that MOPD request, and if that happens, then Sharepoint redirects to the file directory page -- and that directory page ends up being opened in the browser instead of the intended link/document.
Again, this only happens sometimes and not others. When it does happen, I've found a clumsy workaround that will correct the issue for about a week or so. I can't reproduce the issue during that week, I just have to wait for the workaround to expire (I obviously don't fully understand why my clumsy workaround works).
It doesn't seem possible to manipulate the particulars of the MOPD request. If possible, I'd love to be able to dispense with MOPD entirely, since I want all the files I'm linking to via Access to be opened as read-only anyway. Unfortunately, I don't think that that is possible either.
I've found some info on this in another SO thread HERE. I still am not quite at the point where I feel I'm ready to submit an answer to this question, but I have some ideas as to what sorts of things may function as an acceptable workaround.
It would be helpful if anyone had any ideas as to how I might be able to reproduce the issue on demand, rather than simply waiting another week for whatever keys/cookies/settings/etc to expire again. I'd need to implement any possible solutions entirely on the Access side of things if possible, rather than on the Sharepoint/server side. Thanks again for any suggestions!
I'm posting this as an answer now, but will avoid accepting it until I've had a chance to verify that it actually works.
I am inserting some code that will run on DB startup. It will open a (an invisible) form that has an Access WebBrowser control included. I'll have that control navigate to a specific file on the Sharepoint site. I believe that it is actually this action that somehow causes the link problems to resolve for a week of so.
This form will run silently in the background, navigate to the sharepoint file location, and then close. This should hopefully refresh whatever characteristics of the MODP request that are present when the links work properly (and are absent while they aren't working properly).
In essence, I'm hoping this approach will have the effect of resetting my (approximately) one week window of desired link functionality to start anew each time the database is opened. In other words, I'm thinking that this will work, although I still don't fully understand why.
Wish me luck!
;)
The mailto links on the following page do not work in Chrome 32.0.1700.107:
http://accelerate.numa.paris/Accelerate-Apply
I have checked Chrome's settings and the associated handler is Gmail, other page with mailto links seem to work correctly as they generate a new email in Gmail, for example:
W3Schools mailto example
A problem with Chrome settings is therefore to be excluded.
I have read that the problem might be linked to Google Analytics, unfortunately I do not have access to that as the page has been created within a CMS.
Any help regarding the nature of the problem and possible solutions that do not involve using javascript are welcome.
The issue seems to only affect users logged in with an account of the NUMA website, therefore this will not affect the average visitor.
The reason why this is happening would be difficult to answer for anyone that doesn't have an account and is probably less critical at this point.
For some reason my homepage is displaying older content to certain users. So much so that content from many months ago is displaying in their browser even though the html content is currently completely different. I suggested a clearing of the cache but the problem persists. Has anyone come across this problem before and what solutions were used to solve this?
Are you using Wordpess?
If so you may have installed a plug-in at some point called Hyper Cache or something similar, turn it off and then tell them to refresh the page,
Aside from that It could be a DNS issue with crap hosters (happened to me only the other day)
Can you give us a URL etc to check out?
How does Google Toolbar determine the language of a page to offer translation from it?
Google is mis-identifiying a simple login page on our site as Filipino and offering to translate it into English. I've tried added a lang="en" attribute to the <html> element of the page, but that seems to have made no difference.
Anyone know why this is happening?
Edit: It's a login page. The text of the page consists only of the following:
Admin
Log Out
Admin Panel Login
Username
Password
Plus a logo and some input boxes.
When I press the translate button, it doesn't seem to change anything.
One way you can fix this problem is to let Google know it made a mistake on translating your page. Not a real solution though, especially if there's a whole website dealing with this issue.
According to this article on multilingual websites from the Google Webmaster blog, Google's crawlers ignore language metadata such as the "lang" attribute and infer the language from the page content. Their explanation is that the lang attribute is sometimes auto-generated and therefore not reliable. Perhaps adding more English text to the page and ensuring that all the English is well-formed may fix the problem, although submitting a bug report to Google is a better way to fix the problem than adding random English text.
I had this problem on an aspx form I was making. By means of process of elimination, I was able to identify the problem for me was in my calendar control. I was using the calendar control and in my skin I was setting the DayNameFormat="Shortest". With this property, I had the issue, without it I did not. What this property did was take my days of the week and change them from "Mon" to "Mo". I'm speculating that the Google Language inference was reading "words" like "Mo" and "Tu" and using this to guess that this was Filipino. Since I didn't have many other words, this must have been enough of a weight to determine that the page was Filipino.
Hope that helps!
jMo