Problem:
When I run a Flutter app as a web app in a browser, I can use the browser's text search function Ctrl + F to search for text on the page. The search function finds all of the instances of the search term that are currently shown on screen, but it does not find all of the other instances of the text that are currently out of view.
Example:
In the example below I am searching for the word tile, which is used 8 times in total: 4 times in the blue tiles and another 4 times in the purple tiles.
However, when I search for the word tile, the browser only finds the 4 instances of the word that are currently shown on the screen at the time of the search. It ignores all instances of the word that are not rendered on the screen at the time of the search.
Documentation:
The Flutter and Dart documentation does not have any information on searchable text and I do not see any other similar widgets or properties available.
Attempts: I have tried using a SelectableText widget, but the same problem persists.
You can use element = document.getElementById('searchable_text') and element.textContent || a.innerText. See JavaScript tutorial on W3Schools.
Resources:
To create a list and assign it an Id, look at Get Started from Dart docs.
To select elements of the HTML document, read querySelector on Dart docs.
Tell us what worked for your!
This is something not supported by Flutter web yet (tracked here https://github.com/flutter/flutter/issues/53585).
One workaround can be to provide an in-app search bar for list views.
As flutter draws everything on canvas in web, android and ios so far so it doesn't support it.Means whatever you see, Text, images, etc on any flutter app it is just the drawing made on canvas.
If you scroll your page to the bottom before making a search, you should be able to find all the records you expect.
I believe those contents are not in the DOM until they enter the buffer of your viewport.
Meaning, they don't exists to the browser almost until you see them on your screen.
As for infinite lists, Flutter generates the rest of the DOM objects of your page while you scroll.
After scrolling, I can search and find all the words I'm reading, I see them highlighted.
The browser in not able to center on it when hitting Return or UP and DOWN arrows.
Related
For an application I need a document that is able to record and display among each other any type (text, audio, video, HTML, maybe PDF) that the user enters or inserts.
At first I wanted to use a listview with different types of widgets (textfields, video via plugin, webview via plugin etc.), but it seemed much too complicated to me. For example, how could I have selected parts of a text field, the following image and parts of the next text field at the same time?
Actually, the document format that I need already exists: HTML. If you set the attribute "contentEditable" accordingly, it is not a big problem to let the user change the document in any way with the help of JS. And this is exactly my problem: If I use the Webview (Developer Preview) of the Flutter team (webview_flutter), the attribute "contentEditable" is apparently ignored. I can't mark text and no keyboard appears.
Am I doing something wrong or does the plugin not (yet) support this attribute? Otherwise, is there an alternative? I have to say that I am an absolute beginner in Flutter.
I know I can get the whole body of a document with context.document.body.getOoxml() and the current selection with context.document.getSelection(), however I can't find a way to establish what is currently on screen and what is not...
Is there a method in the Word Office JS api to retrieve only the content currently displayed on the screen?
There isn't a solution for this. The way some of the JavaScript libraries in web pages are able figure out this problem is through the view port.
Example here: https://www.customd.com/articles/13/checking-if-an-element-is-visible-on-screen-using-jquery
See another helpful SO answer here: Get the browser viewport dimensions with JavaScript
Now - Word however uses HTML as a way of formatting - and not as a way of directly displaying things. So even if you could run the same library on the HTML - it wouldn't have the same context.
The best you could do is to get the height of the visible space (which should be the same height as your add-in frame) and attempt to do some mapping. You would have some weird edge cases though, like if the font-size is different, or you have a page-break in the view etc...
I am using the Pikachoose plugin for the image galleries on my website (http://www.clare-eileen-callahan.com/inthehangar/). Everything seems to be working except for the thumbnail carousel. They just pile up on the bottom of the page, where I want the carousel to be horizontally scrollable, so that only x amount of thumbnails are visible. I can't figure out what is going on with the CSS and Javascript that is preventing it from displaying as it should.
Here is the code I'm using: http://codepen.io/anon/pen/ybExq
Sorry there is a lot of it for the plug in!
For whatever reason, there was an unexpected element in the original jquery carousel script. I was able to find it by breaking apart the script into short lines and referring back to the console.
I am up to create a section on my Android Home screen similar to this one,
but cannot really figuring out where to start. I mean is this a ListView I should go with? or are these simple images that are placed as different objects surrounded by straight lines? In either case, how to put these things together, is a question that I am wondering..
You can either use:
a GridLayout (for API < 14, there is a support library available somewhere on GitHub)
a vertical LinearLayout containing two horizontal LinearLayouts
a single RelativeLayout
For the buttons, use TextView or Button with a top drawable.
Please note that the dashboard pattern is now discouraged (link 1, link 2) (you should present useful information to the user on first screen such as there latest trips, friend's news, ...).
Instead of that, you could put your buttons in a sliding menu (jfeinstein has a nice implementation on github which can be integrated within an hour)
I find some iphone book apps have such feature:
One screen one page of text without scrolling. The text can just fit into the whole screen with linebreaks and indentations.
I'm curious of how to implement this. How could I decide the length of text that just fit into the screen. And also, given the whole text, I can calculate out the number of pages.
If this is not possible to be done on iPhone(runtime?), then is it possible to process the text before storing it in app? I mean I calculate how many pages I need(how to split the raw text), probably how many lines per page.
I think this is what you are looking for
iPhone SDK: How do you measure the width and height of a string using Quartz?
The accepted answer gives methods you can call on NSString to calculate sizes
What I did for TouchTomes' books was have two iPhone apps. One was the reader that showed up on the App Store. The other was a renderer that calculated what could fit on each page, that only needed to be run in the simulator to create a book DB that the reader could use.
It would throw up a bunch of text, say 100 words, and see if that overflowed or underflowed. If it underflowed, more text was added (say 20 words) and it would binary search until it found exactly how much text would fit. Then it stored in a SQLite DB a row saying "page 12 shows words 100-228" for example. The app would go through this for each font. Another table held all the words in individual rows (!). An optimization step would chop that table down, combining words that always appeared on the same page no matter what font.
I used a Webkit display so the book could include HTML formatting. Now that really complicated the page breakup (e.g. had to keep italics going from page to page) but it let me include some fancier formatting in the text.
Then the reader app had very little to do to display pages; from the page id look up what range of words go on that page, then throw that text up into a webkit view. The user could jump between pages all over the book very quickly, all the hard CPU work had already been done by the rendering app.