Text search problem - doesn't locate found text

[markeh 42]

In the last few days I've seen a new problem.

A text search of a long document marks the searched string, but no longer locates it withing the viewing area. If I scan down (quite a distance usually) the searched string will be marked. But I have to find it, making the search of only limited value.

This seems like a new bug. Anyone else seeing this??

IOS version 17.5.1/ EN 10.101.1

 

[gazumped 12,039]

Maybe try a force quit / uninstall / power cycle / reinstall?

[PinkElephant 8,730]

No need to kill anything, on iOS (mobile ?) this is expected behavior.

Like it or not.

But there is an easy way to be taken to the highlights: I assume you searched for notes by entering the search term into the global search field. You found the note, and have it open now.

But it shows the title and the topmost part, instead of the search hit further down.

Don’t start scrolling. Instead hit the 3 dots top right. Select the option „Search in Note“.

A search field will show on top of the screen. It already holds the text you have used to find the note ! It will show how often it is found in this single note. And it shows arrows to jump between the places where it’s found.

Using these arrows will cycle the view through the document, from hit to hit. Where it fails will be search results found in multiple attachments.

But that’s discussed in another thread already.

[markeh 42]

No, this doesn't correspond to my problem.

* I start with the note in question, I already know where what I'm looking for is - somewhere withing a specific text document.

* I search "Find in note"

*  I get <1 of 5>, or whatever the count is.

* Hitting < or > changes the count, and changes the part of the note displayed. But no longer displays where found text (1, 2, etc... ) is visible. I have to scroll down for some distance to find what is marked by the search. It's found and marked, just not displayed.

- - my guess is EN is now miscalculating where to display. Just a guess.

This has been a multiple-times-a-day activity for some years. Worked fine, now no longer works, so a change in behavior and I think a bug.

I created a new long document to test if it was just something about the few notes I regularly search - same problem.

Just wondering if other  people saw this, before I entered something in tech support.

 

thx, for your response.

 

 

.

[PinkElephant 8,730]

It looks like there is a small bug in the In-Note-Search: It doesn’t place itself on the first hit in a note.

When you tap the „next“ arrow, it correctly moves to the second occurrence. And then to the third (picture), and so on.

When you go back, it will correctly move the screen to the first, and highlight it. So even when the initial match is missed, you can still go there.

If it annoys you, issue a support ticket.

[markeh 42]

12 hours ago, PinkElephant said:

It looks like there is a small bug in the In-Note-Search: It doesn’t place itself on the first hit in a note.

When you tap the „next“ arrow, it correctly moves to the second occurrence. And then to the third (picture), and so on.

When you go back, it will correctly move the screen to the first, and highlight it. So even when the initial match is missed, you can still go there.

Not for me. EN never displays the found text, type <  or > all day long.

I suppose I must admit I'm annoyed by bugs, especially those so easily seen.

 

.

[PinkElephant 8,730]

Talking about text in notes, or in attachments ?

[adriak 0]

I am also having this problem. It is no longer working to search for text within a notebook. It shows that it is in the notebook by saying 1 of 1 or 1 of how many ever times it shows up. But it doesn't pull it up in the viewing area on my ios app.

[markeh 42]

8 hours ago, PinkElephant said:

Talking about text in notes, or in attachments ?

Just plain text. No attachment, no formatting.

[markeh 42]

In response to the query from EN, the problem still exists - IOS 10.103.0

Since finding information is a key part of EN value, still a big problem.

A simple text search and display can't be that difficult.

To restate, text strings are found, but the IOS display doesn't locate them - I have to scroll some distance through the document to find the marked text.

 

.

[PinkElephant 8,730]

To restate, the way to locate text has been described in this thread. The TO has not demonstrated this description wrong, so just for the record:

Text is found and highlighted. The first occurrence (and only this) is not located on the first attempt. Jumping to the second and back to the first solves this lapse. This need to jump to and fro is certainly a bug, but text is found, highlighted and located on screen in general.

Repeating otherwise doesn’t make the opposite claim more true. So even if this posting by the TO has merit in pointing to a certain bug, it is in its totality misleading.

[markeh 42]

16 minutes ago, PinkElephant said:

Text is found and highlighted. The first occurrence (and only this) is not located on the first attempt. Jumping to the second and back to the first solves this lapse. This need to jump to and fro is certainly a bug, but text is found, highlighted and located on screen in general.

This is wrong, as it was the last time you posted this.

I can jump back and forth "<" or ">" all day long, and never have the selected text in the view window.

I have tested this on text docs already in EN, and created new, pure text docs just for this purpose, both have the same problem.

In a long document the found (and marked) text can be a long scroll away, making the find function essentially useless.

For a product designed to store and retrieve information, not being able to find what's stored remains a major bug.

The text doc I was working on today is 96 pages long. That's a lot of iPhone scrolling. Of course I have to realize that a 96 page text document is a serious challenge to the limited power of modern computers.....

.

[PinkElephant 8,730]

Then your iOS behaves differently to mine.

Since mine proves it is possible to do what I describe, your install is broken. Generalizing from a broken install leads nowhere.

Uninstall, dump all data, make a forced restart of the device, reinstall, log in, try again.

Or contact support ...

[markeh 42]

Maybe. It's a bug - a bug in your install, and in mine.

I have contacted support, provided requested documentation. Still a bug.

A core function that should work.

 

[PinkElephant 8,730]

Again: The core function works. It has a lapse, with a known workaround.

Report it to support, I hope they put it on their long list. There are some real problems currently that require dev attention, not nuisances like that.

As long as you shout „text search is broken“ (which implies „completely“), you deserve to be confronted with posting wrong, misleading information. Which is bad style, and a breach of the forum code of conduct, asking for a correct presentation of facts.

If your individual install is broken, follow the advise already received.

[iceman melb 23]

The issue is listed on the bug tracker. Hopefully they restore the search back to search parity like in Evernote legacy 

[markeh 42]

On 9/1/2024 at 4:32 AM, PinkElephant said:

Again: The core function works. It has a lapse, with a known workaround.

Wrong again.

[markeh 42]

7 hours ago, iceman melb said:

The issue is listed on the bug tracker. Hopefully they restore the search back to search parity like in Evernote legacy 

Is this what you are referring to?

Aug, 22, 2024

Marco

⚙️ In Progress Issue with search within note

I hope this represents the problem I see on IOS. The tracker is a little short on details.

thx,

[iceman melb 23]

Quote

I hope this represents the problem I see on IOS. The tracker is a little short on details.

Unified code so you would expect it to fixed once deploy on many platforms

[PinkElephant 8,730]

Actually the unified code is different between mobile and desktop, and somewhat different between desktop and web.

Since we currently have issues on iOS (and before for a very long time multiple issue with Android) I’m not even sure about how unified the approach on mobile really is in the implementation.

The bug tracker probably reflects the current status - if an issue is reported from one platform, they probably document it as such, even if later on it shows to be a cross platform issue.

[iceman melb 23]

5 hours ago, PinkElephant said:

Actually the unified code is different between mobile and desktop, and somewhat different between desktop and web.

I thought the whole point of moving to Electron is to have a unified code base. Oh well lol back to reinventing the wheel...

[PinkElephant 8,730]

On desktop Electron is used. On mobile it is React, I think.

It is obvious that feature parity is always a relative term. First from the basic concept desktop and mobile is fundamentally different (like the ability to handle several notes at once vs. only the one open note). Second there are differences dictated by the OS (like the note switcher shortcut: ctrl-Q on Windows, cmd-J on Mac. On a Mac cmd-Q would quit the app).

Looking from where the native clients have been, the difference is huge. Former desktop even had different code (32 bit on Windows 6.25 vs. 64 bit on Mac 7.14). This meant no carry over at all.