I've made a watch-as-I-type real-time chat service in Meteor, but I'm having trouble with the built-in element preservation feature in Meteor. Basically, I need the current chat message div to not be updated while the text input in it has focus. The documentation has the following instructions:
Another thorny problem in hand-written applications is element
preservation. Suppose the user is typing text into an element,
and then the area of the page that includes that element is redrawn.
The user could be in for a bumpy ride, as the focus, the cursor
position, the partially entered text, and the accented character input
state will be lost when the is recreated.
This is another problem that Meteor solves automatically. Just make
sure that each of your focusable elements either has a unique id, or
has a name that is unique within the closest parent that has an id.
Meteor will preserve these elements even when their enclosing template
is rerendered, but will still update their children and copy over any
attribute changes.
Following these directions, I set a unique id for my input field to make sure it doesn't get re-rendered while I'm typing in it. But now I'm facing the following two problems:
The other person's chat message updates as they type, but this update pauses while I'm typing in my own message. As soon as I stop typing (even if my input field has focus), their message starts getting updated again.
When a new message is created and its div is inserted, my message gets updated / re-rendered even if its input field has focus. This causes it to lose focus suddenly.
You can test this out with two different computers/users in the same chat room at http://babble.im.
Is this a bug in the Meteor code, or my own? How can I find out?
Edit:
Ah, I think I found the reason for the first problem:
Meteor normally batches up any needed updates and executes them only
when your code isn't running. That way, you can be sure that the DOM
won't change out from underneath you. Sometimes you want the opposite
behavior. For example, if you've just inserted a record in the
database, you might want to force the DOM to update so you can find
the new elements using a library like jQuery. In that case, call
Meteor.flush to bring the DOM up to date immediately.
I guess my code was running while the user was typing, so the DOM wasn't being updated. I'll try to use Meteor.flush to fix it. Now what's up with the second problem?
The reason for the first issue is that Meteor used to freeze all changes to your local database cache while any methods were in flight. Meteor 0.5.1 improved this to only freeze changes to the documents that you were modifying locally. I suspect that Meteor 0.5.1 fixes this. See http://meteor.com/blog/2012/11/19/latency-compensation-improvements-coming-soon-in-meteor-051 for more information.
The second issue is probably addressed by the preserve-inputs package added in Meteor 0.4.2, but it's hard to be sure without more details.
I'd love to know if your problems still exist in current versions of Meteor!
Related
I am relatively new to coding on Swift and Xcode. When I was attempting to fix the design of my app, I unchecked the "Use Auto Layout" button assuming that it would simply shut off auto layout for that specific entity (An MKMapView in this situation):
Unfortunately, this removed all the constraints that I had for the entire app! I quickly tried to revert my changes by rechecking the box but it did not return to normal. Are all my constraints gone forever or is there a way to recover them?
Unfortunately, my repository is slightly out of date and I would lose a lot of work if I were to reset with the most current version saved. Any help would be amazing and really end the extreme amount of stress I just placed on myself. Thank you!
Sadly, your constraints are probably gone. Unchecking this box removes all constraints.
If you did not close and open your project since unchecking the box, you can try and undo the change, it will revert to the previous state if the conditions are ideal.
When I try to delete or edit a node in my realtime database, I always get the info that I have to select a key with lesser elements to change something, else it is in read-only modus.
But when I click a low level node, nothing happens. So I actually can change nothing in my DB from console :(
A week ago I didn't see this warning and everything works great!
Any idea how I can get back to working version?
I also think the german translation is not very good, because it tells me that I should activate another mode. In English it says, that the mode got activated.
You're mixing three things here:
Your database console switched to read-only mode, which happens when you have a certain amount of data under it.
The warning is badly translated. Please file a bug report for that.
The database console doesn't handle clicks correctly anymore. I already reported that internally last week, and added your report to it. This bug has been fixed internally and will go into production by May 23.
Update 5/24/17:
Problem resolved. Works now.
It seems the ability to click on a child node and promote it to be the top element of the tree is broken. Doesn't work for me either, even on a small database that is not in Read-only & non-realtime mode. I'm almost sure it was working a day or two ago.
I'm seeing the failure when using Chrome. Just tried Internet Explorer. Its works there.
Is there a way via extendscript (jsx) to get the visibility status of Photoshop' guides?
The code to show and hide the guides is the same code as it 'toggles' the guides on or off so it must know the status when this code is executed, but how do I get at it?
I appreciate this could be done via a preference switch but that seems an awkward hack for something this simple, especially as something somewhere must be accessing this 'property' during execution of the 'toggle' code.
What would be great is to have activeDocument.guides.visible property, returning either true or false. Is there anything like that?
EDIT:
OK. Further investigation reveals that creating a guide using guides.add does not automatically toggle guides ON, however, using the code generated via the scriptListener does.
I would rather use guides.add as its only one line of code compared to fourteen so in order to toggle the guides to ON I thought I could run a function that created and then deleted a guide using the scriptListener code during the onLoad of the HTML.
This works great, except getting this function to run only when a document is opened is now the new problem.
documentAfterActivate is supposed to be the code to do this except it doesn't work unless a flash panel such as kuler is opened first.
So the question now is really what part of the flash code is allowing documentAfterActivate to work properly and how can I use it in my code instead of opening a flash panel I don't need?
It doesn't look like you've got a direct toggle option. You'd need to record the position of the guides somewhere and use script listener code to clear them when you wanted to toggle them off and use the add method on the Guides object to re-add them.
Keep in mind that even getting to the guide position via the photoshop DOM wasn't avail before CS4 I think? maybe CS5.
And i realised I just mis-read your question quite a bit. Anyway, this way you'd also know if the guides were visible based on whether or not they are there :) But yes, it isn't as nice as it could be.
The solution:
As stated, the workaround is to create and delete a guide with the fourteen lines of code from the scriptListener.
This toggles the guide visibility to ON regardless of its current state.
I can then save this status as a preference using putCustomOptions.
A function to do this is fired during the onLoad of the HTML but only when a document is opened otherwise guide creation fails.
documentAfterActivate does not work as expected unless a further flash panel (such as Kuler) is also opened beforehand.
An alternative to documentAfterActivate is to register the open event using CSevent instead.
The code can be found HERE.
Pattern for pagination is currently on a after 1.0 roadmap for Meteor. Are there any examples or suggestions how to do it now? So how to nicely do an infinite scroll by subscribing to new and new elements as user is scrolling to the bottom?
I recommend that you try my package, Pages: https://github.com/alethes/meteor-pages
It's extremely easy to use (you can set it up with just one line of JavaScript), yet very customizable. It features: incremental subscriptions, local cache, neighbor prefetching, request throttling, easy integration, multiple paginations per page, bootstrap 2/3 styling, failure resistance, built-in iron-router support and a lot of settings that can be modified on the fly, without reloading the page.
There is a package on atmosphere.meteor.com for pagination that should get you started
https://github.com/egtann/meteor-pagination (Pagination)
https://github.com/tmeasday/meteor-paginated-subscription (Pagination with publish)
The second one actually sends down one page of data at a go instead of all the data at once so if you have loads of data it might help with that. With the infinite scroll you would have to attach a manual scroll listener and put in the new data by increasing the size of a page as you scroll down (not specifically moving to page 2).
I'm a bit unsure on what pattern to use specifically because using page size might be a bit troublesome unless you're able to get it to work right with reactivity which should be possible if you're able to seperate your {{#each}} block helpers so that its for each scroll down, perhaps using Meteor.render so that the entire set of data already available isn't re-rendered.
It might also work if you put the data in div block containing a scroll overflow instead of the above so that it does re-render but their position in the scroll remains the same, in effect making the re-render unnoticable.
We have an application running flex sdk 4.5 and have recently encountered an issue with textInput fields which we have not been able to reproduce on our end for the better part of a month now.
Here are the symptoms:
Users opens an input form which contains several input fields (combo boxes, calendars, text inputs, etc)
User clicks inside a text field
Users types (obviously!)
** Nothing appears in the text input - we have validators on some of these fields and they do kick in properly (ie. user sees red box around textInput disappearing)
User moves cursor outside of text input field and text appears
Give or take, this is the test case we've been provided. We have been unable to reproduce this and I'm reaching out to see if anybody has heard of issues like this in the past.
They are running our flex application in the following environment:
Windows XP SP3
IE 7.0.5730.13 (locale = en-gb)
Flash Player 10.3.181.14
Upgrading either of these components is not an option. Installing the flash player debugger is not an option either.
Now we've setup a pc exactly the same way as they have on their end and still haven't reproduced. So we're really stuck at this point :)
Any suggestion is greatly appreciated. I'll provide any additional info needed.
-Marc
Feb. 2nd 2012 - Update
As I noted in my comment reply to shaun, it seems our customer was more or less precise in their description of the issue. We ran a webex session with them this morning and actually saw the issues first hand.
Here's what happens:
- User loads our application via its url
- User is able to input data and pretty much do any function for a 'random' time period
- All of a sudden, the issues start (there are more symptoms than just the one I originally mentioned):
1. Users type in text input fields and they won't see the text appear until they move the cursor out of / into any other component (could be entering an hbox, exiting a text input field, etc)
2. Combo boxes behave more or less the same. They can drop them down, but then the mouse wheel no longer refreshes the list. It actually scrolls in the background, but until the user moves the mouse, the list does not refresh
3. We also communicate between the server and client via an amf channel. The events make it to the client, but again, they won't see the screen refresh until they move their cursor.
So basically, the application still seems to work, but the screen is no longer refreshing. Could it be something to do with an invalidate / update of the display list that doesn't kick in? We'd like to get them to install the debugger version of FP, but that doesn't seem to be an option.
Another thing to keep in mind: they have a VERY bad internet connection. They average around 1-1.5mbps (megabits) which is enough for our app, but I just thought I'd let you know.
We learned that they also use a Citrix presentation layer to deploy IE 7 to the end users. We've received confirmation from the end user that even if they launch IE on their workstation (not through citrix), they get the issue also.
Another note is that we've seen no errors in our web server, jboss or application logs...
So that's the update I've got... anyone have more thoughts on this? We've more or less discarded the fonts being an issue at this point since the issue affects more than just 'fonts'. Is everything on the screen not updating anymore.