I have some issue here with fullcalendar selectable and i am not denying that it could be also my coding problem. Either both of them, i'm having an issue where i need to click and hold in order to create new event and even drag instead just click and create and click to drag. No. I need to hold and wait for a seconds, and then i can select it afterwards.
Is it something wrong with my code or this issue has been centered long before? I can't find on google about fullcalendar selectable problem though. I use Ionic with localstorage and chrome.
If i am using eventClick/dayClick, it is fine. There's no need for me to click and hold the button. However when i am using selectable: 'true' and also selectHelper: 'true' the problem that i just mentioned has occured.
NOTE: When implementing my coding on JSfiddle, it is working fine but when i see my calendar on chrome localhost, it's making that annoying problem. In addition to that, when i'm build into .apk, and i use it on my phone, the problem still occured.
Anyone got solution?
touch devices are different than browsers, fullcalendar have a documentation for supporting touch devices.
you can set the delay for selecting a cell using longPressDelay
hope it helps.
Related
I want to know what disabling CSSOM View Scroll Coordinates flag in chrome://flags does and how can i replicate this behavior using code in my ReactJS app.
Additional information :
It seems after Chrome 85 update, ag-grid RTL support breaks and the grid is not able to scroll the content and sometimes the cells becomes white, i had to dig very deep into the past questions and try a lot of far fetched solutions to find what i have.
I found out that disabling CSSOM View Scroll Coordinates in chrome://flags will fix the bug!~ but the problem is i don't want to force my users and teach them to do this just so my app works, so i thought what ever disabling CSSOM View Scroll Coordinates does, maybe i can replicate it using css code or some other code
I have already reported this issue in ag-grid's git-hub but i'm still waiting for them to offer a solution in the mean time if i can get this to work only using code, it would be great as i have a lot of users which are not able to use my app just because of this simple bug ..
Thank you.
I'm in Xcode 6.2 Beta 3 (Build 6C101), I've added a menu and two menu items to my Interface Controller, and created IBActions for both. I've given them titles and images, but when I run the app nothing displays.
I've read
https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/Menus.html
and can't see anything about need to show menu items programatically - what am I missing?
You do not need to present the menu programmatically. The only thing you need to do is wire each button to IBActions in your Watch app extension.
The most likely issue is caching of the previous Watch app storyboard. Do a clean build and try again.
Finally, as you likely know WatchKit menus only display on a "force press". They cannot be used for the main interface of the Watch app. In the Simulator, a click and hold with the mouse will simulate a force press, and the animation will make it clear when you have done one, even in contexts where it doesn't do anything.
This was solution for me- Go to Hardware->Touch Pressure->Deep Press then try tap on watch simulator.
I have recently encountered this issue on a real device, although the menu was working as expected on the watch simulator. In my case, the problem was in SF Symbol that I've used as an image.
Everything was fixed after replacing it with an image from the assets catalogue.
I have a Dojo EnhancedGrid connected to a JsonRestStore. clearOnClose is set to true on the store. Usually I refresh it by doing
grid.store.close();
grid.setStore(window.store.tester);
Or
grid._refresh();
This works fine in every browser, but not in the newest version of FF9 (in version 4,5 it worked well).
In FF9, nothing happens at all and the store is not cleared or refreshed. Oddly, it does work after trying a few times and debugging it. But when I clear the browser history and cache and then try to refresh, it never works.
Does anyone have a clue what happens? What could be different in FF9 and is there another way to definately refresh the grid?
Are You using Firebug. If yes, then try switching it off and reloading the page. Dojo grids don't get along very well with Firebug.
Thanks for the suggestion. I found the reason now, it was some screwed hashtag logic which caused the grid to be refreshed twice at a time in Firefox. I corrected it and now it works.
I'm having problems making FullCalendar fully accessible. I'm using the default month view and can't access the next, previous, and today buttons on the top right without using a mouse. If I run a screen reader, I can access those buttons but not without running the screen reader.
And on another note, I currently am using tool tips that pop up when you mouse over an event title to display more information. If anyone has any tips on how to make those accessible to a screen reader or accessible without a mouse, I'd greatly appreciate it!
Regarding the buttons, I would advice that you write new buttons if accessibility is important. These buttons you could then hook up to your own javascript functions that moves to previous and next.
Check out this documentation example
Regarding the second problem, I think that's the same problem not just for physically impaired but also for things like mobile browsers. My tip would be to avoid onmouseover if the information that appears is really important.
customers does not want to allow user to use back or forward button. Just a clean page without commandbar and toolbar, same for FF an IE.
Disabling them is not an option as now.
You cannot change that kind of thing in a existing window -- the only way you can make those disappear is by opening a popup, specifying they should not appear in that popup when it's being opened.
Still, note that you should not try to disable those buttons nor have them disappear : your application should work fine with them, handle their actions -- after all, it's one of the few things users have understood in browsers...
And as a user, this is disturbing and annoying :
I don't like popup windows -- and I'm not the only one who doesn't
I don't like when a website tryies to take control over my browser
It will not always work anyway.
And, as a sidenote : even if the back/forward buttons are not displayed, users can still use Ctrl+left/right or some kind of equivalent !
I know this is not easy, but a part of your work as a web-developper is to explain your clients how Internet and web-applications work... not the same way as desktop applications !
If you can force your users into IE (can't believe I'm suggesting use of IE!) you can do this trick. Try running this from the command line
"C:\Program Files\Internet Explorer\iexplore.exe" -k
This will force IE into kiosk (or full screen mode), similar to pressing F11 when in a usual browser session.
PS. I agree with the other answers suggesting this should be discouraged but there are instances (such as when the end user really can't be trusted) that this is a good solution.
No, there's no other way.
However, this is extremely annoying behavior and should be greatly discouraged. This isn't a code issue to solve...this is behavior that shouldn't be implemented at all.
My opinion here, you have a client problem not a code problem. Whatever standard is the expectation, and the user has the expectation of having their back/forward buttons, break that and you break their experience.
Ever see a Windows application that removes the taskbar? That's the equivalent...
I don't think there is a reasonable way to disable the behavior. You may get rid of the buttons in various ways, but the behavior is still there (through keyboard commands, popup menus and so on).
The only reasonable way is to make your web application follow web semantics, and make the client realize this.
many web based ERP (for example) does not tolerate people using navigation buttons. BUT these web applications handle the fact people use these buttons and do not crash. That's what you should do. If each time people use the back button, they get an error message, they will quickly stop using it.
The solution that used to work in IE was adding a startup script with one line:
location.forward();