Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Highlighted match not visible in code view for SCX/VCX #27

Closed
TamarEGranor opened this issue Oct 28, 2022 · 21 comments · Fixed by #33
Closed

Highlighted match not visible in code view for SCX/VCX #27

TamarEGranor opened this issue Oct 28, 2022 · 21 comments · Fixed by #33

Comments

@TamarEGranor
Copy link

ℹ Computer information

  • VFP version: 9 SP2 Build 7423
  • GoFish version: 5.1.002
  • Last GoFish version w/o bug (if available): 5.0.205

📝 Provide detailed reproduction steps (if any)

  1. Do a search in GoFish whose results include method code
  2. Highlight a method match in the results grid

✔️ Expected result

The highlighted line that shows the match would be visible in the Code View pane

❌ Actual result

The top of the method shows in the Code View pane. You have to scroll to find the highlighted match.

📷 Screenshots

image
@mikepotjer
Copy link

I'm seeing the same issue. Same VFP version, same GoFish version.

@lscheffler
Copy link
Collaborator

@tamar, @mikepotjer All I can say is, I see this odd behaviour in 5.0.205 too, and have it on my privat odd things on gofish to fix list from start. It was this way even before I touched GoFish at all - at least on my comp. I do not see how this navigates.
@TamarEGranor, I was a bit surprised to see it moving during your presentation.

Conclusion: It's something I look up, but since I need to learn what moves that browser window first, it is postponed after my recent work.

@TamarEGranor
Copy link
Author

FWIW, this has always worked for me until this version.

@rikaye
Copy link

rikaye commented Nov 8, 2022

As mentioned by Tamar, this started with recent builds of GF. In general, the positioning of the matching line in the code window is intermittent at best. I have not yet been able to spot a pattern. For example in the screenshot below, only 8 of 13 matches in that r3functions.PRG will bring the match line into the view-port. I've seen similar inconsistencies in VCX method matches as well as other file extensions beyond PRGs.

image

@lscheffler
Copy link
Collaborator

@rikaye Thank you.

@lscheffler
Copy link
Collaborator

@ALL I found some time to look into this a bit closer.

I must admit, I'm lost.
My code does nothing on this.
All the navigation is done by some JS on bottom of the HTML used to display the result. This is the same as in .\HTML\GoFish.js
As you can see, there is a window.onload that should do the work. As far as I understand JS (what is not much) it searches for matchline, what exists. Why it is not running is beyond my knowledge. As far as I see, all is there.

So for me, there is 1) no chrome on my machine and 2) JS restricted to nearly 0. I understand if the line is not shown on my comp. The problem remains what's wrong on your comp.

All that is not touched since Matt, so I have no idea what's going on. I need some help here.

Would you please be so kind to gather the latest version running from the repository of this project, breakpoint in gf_resultsform.ShowHTMLCodeView around ine 36 If This.lGoogleChromeFrame = .T. pick a line in the grid and check the value of This.lGoogleChromeFrame? At least the comments say Chrome is needed to scroll to the highlighted line.
Please also try if the old version is working.
I see no way how this property gets set. In no version back to c1dd62b, the last change done by Matt.

Thank you

@lscheffler
Copy link
Collaborator

lscheffler commented Nov 8, 2022 •
edited

@ALL I'm a bit closer. in the method mentioned above, there is a variable lcHTML Would you please check this. This contains HTML code. On the end there is a <script> section. Is this properly formatted on your comp or just one line? On my machine, the textmerge creating the HTML removes the CRLF from the file and squeezes all into a line. If I create a file out of the var and run it in my browser with JS turned on, nothing happens.
If I replace the <script> with the original code from the file, it runs in browser.

So please check

  • Is the <script> section one line?
  • If you recomiple GoFish on your comp, is something changing?
  • what happens on your comp if you use an old version?

I even do not grok why TEXT .. ENDTEXT is removing the CRLF, but this is not teh first time I have problems with that. I remember similar problems on FoxBin2Prg.
The textmerge is on the end of gofishsearchengine.prg GenerateHTMLCode. The JS code goes formated in and unformated out. This is true for the CSS as well. It's easy to circumvent, but it would be nice to understand why it is working as it works.

Update: I have this effect with VFPA as well as with VFP9 SP2 (7423)

@lscheffler
Copy link
Collaborator

lscheffler commented Nov 9, 2022 •
edited

@ALL Found the culprit. Finally.

The problem is that somebody has set up his git for windows in a rather odd way.

The CSS\GoFish.css and HTML\GoFish.js are corrupted. This is, they are UNIX style, line break is just 0h0A.
A bug in TEXT .. TO TEXTMERGE removes 0h0A, even if only Pretext bit 3 - 8 should remove LF.
See VFPX/HelpFile#31

The problem is, that git will alter, if set up wrong, any CRLF to LF on add and back on checkout. If a different machine is set up to keep CRLF / CR / LF while add / checkout, the commited LF will be kept. There is a special page on the installer on git for windows dealing with this installation wide.

I strongly recommend to set git to keep CRLF for VFP use, else it might create havoc as this issue proves.

I will push a fixed version later the day with fixed local git settings. Need to learn this first.

Update 1

Also I need to fix any text file, might take a while. ....

Update 2

The conversion is on git add / git checkout, not push / pull

lscheffler added a commit to lscheffler/GoFish that referenced this issue Nov 9, 2022
@lscheffler
Fixed Highlighted match not visible
34d521b 
Highlighted match not visible in code view for SCX/VCX fixed VFPX#27
fixed corrupted LF <-> CRLF conversation
fixed git settings to prevent corruption
@lscheffler lscheffler mentioned this issue Nov 9, 2022
Merged
@TamarEGranor
Copy link
Author

TamarEGranor commented Nov 9, 2022 via email

@rikaye
Copy link

rikaye commented Nov 9, 2022 via email

@TamarEGranor TamarEGranor mentioned this issue Dec 9, 2022
Closed
@lscheffler lscheffler mentioned this issue Aug 16, 2023
Closed
@Jimrnelson Jimrnelson reopened this Mar 6, 2024
@Jimrnelson Jimrnelson added the can't or won't fix This will not be worked on label Mar 9, 2024
@Jimrnelson
Copy link
Collaborator

@TamarEGranor
@rikaye
@mikepotjer

Tamar, in your original post, you wrote:

_Last GoFish version w/o bug (if available): 5.0.205_

Here's a link to that version:

https://drive.google.com/file/d/1KuLJkO3wKqaz7p6n2VP3urZkHEG_A0qu/view?usp=sharing

You should be able to download it and run it directly from there (I think).

Now it will be interesting to learn whether the code view window aligns correctly or not.

@Jimrnelson Jimrnelson removed the can't or won't fix This will not be worked on label Mar 10, 2024
Jimrnelson added a commit to Jimrnelson/GoFish that referenced this issue Mar 10, 2024
@Jimrnelson
Version 7.0.12 - 2024-03-10
22c98a5 
* Fix for issue VFPX#27, where Code View pane does not always auto-align the match line to be visible.  See Options form, "New in Version 7".
@Jimrnelson Jimrnelson mentioned this issue Mar 10, 2024
Merged
@Jimrnelson
Copy link
Collaborator

@TamarEGranor
@rikaye
@mikepotjer

If the mountain won't come to Muhammad ...

This problem has not been resolved so far because nobody has been able to unravel why the browser control for the Code View pane, which is supposed to align the match line so that it is visible, does not work for all users.

Today I have released an alternative approach (in 7.0.12), which users experiencing this problem can take advantage of.

The idea is simple: set a limit to how many lines are to appear in the browser before the match line.

Thus there is a new option to handle this:

image

I welcome feedback as to whether this works and is satisfactory.

@rikaye
Copy link

rikaye commented Mar 10, 2024 via email

@Jimrnelson
Copy link
Collaborator

rk --

This weekend I have released an update to GF, version 7. I ask that you see if the problem is resolved in that update (after you have also gone to the options page)

@rikaye
Copy link

rikaye commented Mar 10, 2024 via email

@rikaye
Copy link

rikaye commented Mar 11, 2024 via email

@Jimrnelson
Copy link
Collaborator

@TamarEGranor
@rikaye
@mikepotjer

My approach to the problem has nothing to do with the js attempt to align the text.

I simply provide an opportunity to only submit to html a few lines before the match line, rather than all the procedure that precedes it.

In my own own use, I rarely am interested more than the highlighted text and a few lines around it.

@TamarEGranor
Copy link
Author

@TamarEGranor @rikaye @mikepotjer

Tamar, in your original post, you wrote:

_Last GoFish version w/o bug (if available): 5.0.205_

Here's a link to that version:

https://drive.google.com/file/d/1KuLJkO3wKqaz7p6n2VP3urZkHEG_A0qu/view?usp=sharing

You should be able to download it and run it directly from there (I think).

Now it will be interesting to learn whether the code view window aligns correctly or not.

After the experimenting you and I have been doing, I'm not surprised to report that, in fact, on the machine where I've had all the trouble, this version doesn't work either. I suspect that when I first tested, I simply switched to another machine and tested there, and that was the version there.

@TamarEGranor
Copy link
Author

More details coming back to me. It was some upper ascii characters that got munged by git. Anyway I will check out 7. Welcome back. :-) rk
…
On Sun, Mar 10, 2024 at 7:42 PM Richard Kaye @.> wrote: Will do, Jim. rk On Sun, Mar 10, 2024 at 7:34 PM Jimrnelson @.> wrote: > rk -- > > This weekend I have released an update to GF, version 7. I ask that you > see if the problem is resolved in that update (after you have also gone to > the options page) > > — > Reply to this email directly, view it on GitHub > <#27 (comment)>, or > unsubscribe > https://github.com/notifications/unsubscribe-auth/AG3DGP55EARONRTXQMMNGNLYXT3YRAVCNFSM6AAAAAARRFKC5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGQYTCNRTHE > . > You are receiving this because you were mentioned.Message ID: > @.***> >

There was a problem around line terminators that Lutz fixed that seemed to resolve the issue for most, but it never fixed it for me.

@TamarEGranor
Copy link
Author

@TamarEGranor @rikaye @mikepotjer

If the mountain won't come to Muhammad ...

This problem has not been resolved so far because nobody has been able to unravel why the browser control for the Code View pane, which is supposed to align the match line so that it is visible, does not work for all users.

Today I have released an alternative approach (in 7.0.12), which users experiencing this problem can take advantage of.

The idea is simple: set a limit to how many lines are to appear in the browser before the match line.

Thus there is a new option to handle this:

I welcome feedback as to whether this works and is satisfactory.

Bingo! This seems to work for me. I'll have to spend some time figuring out how big I can set the limit and still have it work, but for the example I've been testing with, setting it 10 gives me what I need. GoFish just became way better for me. Thanks!

@Jimrnelson
Copy link
Collaborator

YES! Great to hear!

Unless you have more to add, I am going to mark this issue as closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Version 5.1.005 lscheffler/GoFish
5 participants
@mikepotjer @lscheffler @rikaye @TamarEGranor @Jimrnelson