- AuthorPosts
- June 5, 2018 at 9:55 pm #23320LTTParticipant
I think “Close without Save” command should obey “Do Not Close Last Document by Selecting Close” option.
And I think “Close All without Save” should NOT ask for workspace saving, even if “Do not ask before exiting” option is off.
June 6, 2018 at 4:10 pm #23328Yutaka EmuraKeymasterI addressed this issue on v17.7.94. Thanks!
June 7, 2018 at 1:32 am #23331LTTParticipantWhat about the first one?
June 7, 2018 at 2:26 pm #23340Yutaka EmuraKeymasterAs for the first one, we changed the behavior par your comment on the next beta (v17.7.95). Thanks,
June 11, 2018 at 12:49 pm #23367LTTParticipantSuggestion:
Is it possible to add a “Close All without Save (Current Group Only)” command for daily use, to gain both convenience and cautiousness. When using it, I won’t have to worry whether other windows exist.—————
Issue 1:
“Open in: New Tab” is set.
Grab text from an EmEditor window.
** The new “(Grabbed Text)” tab is empty.Issue 2:
“Open in: New Window” is set.
Grab text.
Edit the grabbed text.
Use “Close without Save” command in the “(Grabbed Text) *” window.
** But the changed text is sent back nevertheless.I guess this is caused by the recent change.
I want to withdraw my suggestion on (and only on) “Close without Save” command, not only because of this, but also because I feel that using “Close without Save” command in a “(Grabbed Text)” window should close the window directly. So if there’s no better solution, please take bother to restore “Close without Save” command. Sorry for that.—————
Issue 3:
Is it possible to make the “(Grabbed Text) *” window have no “*” in the title initially?
I notice the initial status when we edit a snippet in a tab, which has no “*”.—————
Issue 4:
Enable “Do Not Close Last Document by Selecting Close Command”.
New window.
Open a file.
Split.
Close the tab.
Should the split persist?June 11, 2018 at 3:14 pm #23371Yutaka EmuraKeymasterHello,
As for Suggestion, you can use the following macro:
currDoc = document; docs = new Enumerator( editor.Documents ); for( ; !docs.atEnd(); docs.moveNext() ){ doc = docs.item(); if( !doc.Saved ) { doc.Activate(); doc.Saved = true; } doc.close(); } currDoc.Activate();
As for Issue 1, we don’t support EmEditor grabbing EmEditor, please! We will disable this on the next version.
As for Issue 2, we will undo the “Close without Save” command change. I don’t really want to change the specs back and forth. Please think twice before suggesting a change or consider writing a macro next time.
As for Issue 3, I agree. We will change the initial status to no “*” for grabbed text.
As for Issue 4, Currently, the split persists. Do you want the split NOT persist?
June 13, 2018 at 12:10 am #23383LTTParticipantI forgot the “Grabbed Text” cases at the time… Sorry again.
As for the macro, I use “Close without Save” editor.ExecuteCommandByID(4120) instead, in case there’s any “Grabbed Text” tab in the group.
But I don’t understand your last statement currDoc.Activate(). What’s it for since the window is closed?But please don’t disable “EmEditor grabbing EmEditor” if there’s no critical disadvantage.
Could crash on large files? But I never use it on large files.Issue 3-2:
A “Grabbed Text” tab initially has one step of Undo history.
Is this inevitable?Issue 3-3:
Press Ctrl+A and Delete key in a tab. The tab has no “*” now.
I don’t think this is correct logically.
Same result in issue 3-2 when we use Ctrl+Z.> Issue 4:
In that case, I split only for that file. So when job finished, I expect the initial view.
But it’s acceptable if it’s by design.June 13, 2018 at 9:07 am #23395Yutaka EmuraKeymasterHello,
“currDoc.Activate();” was necessary before the “doc.Saved = true;” line because a particular internal code reason.
We can’t allow EmEditor grabbing EmEditor if both documents are in the same group window by design. Why do you need this ability?
Issue 3-2 and Issue 3-3 will be addressed on the next version.
Thanks for all the comments!
June 19, 2018 at 6:14 am #23434LTTParticipant> “currDoc.Activate();” was necessary before the “doc.Saved = true;” line because a particular internal code reason.
Sorry but I mean the last statement, not the one before “doc.Saved = true” in the circle.
——————————
> We can’t allow EmEditor grabbing EmEditor if both documents are in the same group window by design. Why do you need this ability?No I don’t really need “grabbing in same group”.
But I do need “EmEditor grabbing EmEditor” whatever way.
My Tab setting is “Open in: New Window”. So actually I’m using “grabbing into a new window”.
I use “EmEditor grabbing EmEditor” as a fast and easy way to keep a midway version of the text on the fly during a processing.
So please enable it. Thank you.June 19, 2018 at 10:47 am #23440Yutaka EmuraKeymasterAs for the macro, yes, you are right. The last line of the macro was not necessary.
I might think about the ability to grab EmEditor by EmEditor. Thanks,June 20, 2018 at 3:10 am #23446LTTParticipantAnd I think it’s necessary to add some characteristic (e.g. serial number, or even the name of the source control) to the title of the “Grabbed Text” window.
June 26, 2018 at 11:39 am #23493LTTParticipantIssue 3-3 also occurs on Untitled documents.
June 28, 2018 at 3:17 pm #23504Yutaka EmuraKeymasterIssue 3-3 also occurs on Untitled documents.
I am not sure what you mean by this? Are you talking about a normal untitled document (NOT grabbed text)? If so, this is an intentional behavior.
- AuthorPosts
- You must be logged in to reply to this topic.