RJ TextEd

Making any edit in an .html or .js file (only files types tried) and then saving with ctrl-s results in the cursor disappearing and keyboard actions not being recognized until I mouse click the mouse to reposition the cursor.

I can't see anything wrong myself. Are you using some action when saving a file, like "Remove trailing white spaces before saving", or run a script?

Not running anything before saving. It's possible (dare I say likely) that it's something local to my setup. I upgraded from the release version to the beta by merging the beta to keep my numerous configuration changes. I'll kill this install and start fresh when I get the chance on Monday. Bet that fixes things. Will let you know.

Okay, this was annoyingly subtle. The problem seems tied to customizing the browser preview mapping.

I use the following options so I can pickup .js files hanging off a fixed base folder rather than relative to each file's folder. Devd.io is the small local web server I prefer. It's located here https://github.com/cortesi/devd if interested.
(But I don't think it's the issue as it worked fine in the ver. 11 branch.)

When I use the Chrome preview tab at the bottom to preview the file and then switch back to the editor I lose the arrow keys after my next ctrl-s save after an edit. If I delete the custom browser preview mapping and try the Chrome preview again, things are back to normal. I.e. the cursor keys work as expected after saving a change. But putting the mapping back to devd.io again causes the problem to reoccur.

Does this give you any clues?

My wild guess is that after ^S another panel is focused. I have no other idea atm than to switch on all panels, hit ^S and then try to find out which panel is active, e.g. thru arrow keys.

Devd.io seems to use something called "Livereload". RJ TextEd already automatically reload the document you're working on, so you shouldn't need it. Does it help if you turn Livereload off?

Turning off live reload does fix the problem. Guess that the reload pulls the focus after the ctrl-s save. Not sure why ver. 11 worked with it though.

Live reload is a key feature for devd.io so I would rather keep it on since I work with other pages with other editors too. Any way to set a base folder with RJText Editor so I don't have to use devd.io but can still pull in relative paths for .js files? (ex: <script src="/jQuery/jquery-3.1.1.js"></script>)

Every time Chrome has finished loading a page it triggers an event. This is where I change focus back to the editor. I don't know why that doesn't work in your case or why it worked before, but not now.

I've made a small change in v12.0 final and added a 500 ms delay before focus is switched back to the editor. If that doesn't help I'm not sure what will...

Do you mean a 500ms delay after the ctrl-s key combo is pressed? I wouldn't have though saving would take the focus away from the edit panel in the first place.

No, 500 ms after the Chrome components has reloaded the saved file. It's the Chrome components that steels focus when the file is reloaded.

I've compiled a test version. Would you mind trying it out and see if it works?

http://www.rj-texted.se/downloads/beta/TextEd.zip

No change. It still loses the focus. However, I'm wondering if it's worth it to bother even trying to fix.

First, if fixing is worthwhile. The web server contains a file system watcher and sends a notification to the browser tab (via a socket) that tells the page to reload. We're never really going to know how long the reload takes so a fixed delay will only work on small web pages and fast machines. How about checking for lost focus on the text edit panel. If the focus switches to the internal browser panel but the active tab is still the editor, post an event to regain focus back to the Windows queue?

But really, I think a better solution is for me to run two instances of devd. One without the reload for RJText Editor and one with the reload for other locations. It's really small so this seems a good approach.

But best, in my mind, is to allow a base path to be set for the browser tabs. That way the internal option would work fine without redirecting through an external web server. Possible?

--Will

But best, in my mind, is to allow a base path to be set for the browser tabs.

I don't think it's possible using the Chromium component. I've seen other developers request such a feature while searching help forums, but they never receive an answer... It's not something that would be used in a browser so I'm guessing it wont be implemented either.