Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #23320
    LTT
    Participant

    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.

    #23328
    Yutaka Emura
    Keymaster

    I addressed this issue on v17.7.94. Thanks!

    #23331
    LTT
    Participant

    What about the first one?

    #23340
    Yutaka Emura
    Keymaster

    As for the first one, we changed the behavior par your comment on the next beta (v17.7.95). Thanks,

    #23367
    LTT
    Participant

    Suggestion:
    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?

    #23371
    Yutaka Emura
    Keymaster

    Hello,

    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?

    #23383
    LTT
    Participant

    I 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.

    #23395
    Yutaka Emura
    Keymaster

    Hello,

    “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!

    #23434
    LTT
    Participant

    > “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.

    #23440
    Yutaka Emura
    Keymaster

    As 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,

    #23446
    LTT
    Participant

    And 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.

    #23493
    LTT
    Participant

    Issue 3-3 also occurs on Untitled documents.

    #23504
    Yutaka Emura
    Keymaster

    Issue 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.

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.