[BUG] Scrivener now opens with window maximized no matter what

Used to be Scrivener conformed to convention and opened with the window in the state I left it when I closed it down the last time. Now it always opens maximized.

This has not changed. Most likely your project crashes upon shut down and the last window geometry is not saved. Try closing Scrivener in a different mode(Corkboard/Outliner/Single document mode) and check if it restores correctly the size upon restart.

I have this problem too, but my topis entry was completely ignored.

Tried your solution but it does not solve the problem. Since you are the only developer on Windows Scrivener 3.0 project, I realize it is not a topic priority but it is annoying.

Also, it is localized to ONE project not others. By this I mean my working project is affected but the interactive tutorial or other older projects do not have this startup problem.

Sorry fpshed2, sometimes it is impossible to answer all forum threads. If you upload a project which always opens maximized, we might be able to trace and fix this. Send it to tiho at literatureandlatte dot com, if you do not feel like uploading it here.

tiho_d, sorry, I beg to differ. I don’t know where you got the idea of a “crash” from. Nothing of the sort was involved in the app behavior I described.

It changed not in the current version (updated a couple days ago) but in the one just prior to that. I noticed it immediately. I’ve been using Scrivener since February and it has always opened in the state (maximized or ‘restored’) as it was in when I exited. If not maximized, the Scrivener window always opened in the same location and of the same size as it was when I last exited.

This has long been standard Windows behavior. Scrivener used to conform, now it doesn’t.

Actually is conforms nicely. I just confirmed that in Beta 26 using an exisitng file. File opened in full screen. I change to window of about 30% of screen size. Saved project. closed Scrivner. Opened scrivner and same file opened in the new Window position.

Arguing with the DEV, vs listneing will help you work through this issue much better.

  1. He knows what changed in the code, you don’t so why tell him he is wrong?
  2. He is suggesting an example. BTW not all crashes are seen. It could be that the app crashed quietly during the save of the window postiion. Again Dev is not tell you you are wrong, he is talking about a possible cause.

So I would suggest if you want to help fix this:

  1. With the project open, change windows size. Then do an explicit save and close of the project. close Scrivner than open again. Since several of us have confirmed this has worked, That would ID it as a problem that is in your project file. Which still could be a buf.

  2. I would also suggest if you use Autosave. That you do the same. change the window position, wait so you know it auto-saved and close Scrivner. Then open it again. If the new Window position is not saved, that would ID Auto-save as a possible cause.

Asking questions and trying out different ways to reproduce the bug, help fix bugs. telling the developer he is wrong about his own project… not so much.

Also pay attention when others tell you it working, vs making sweeping “YOU ARE NOT COMPLIANT WITH THE UNIVERSE” statements. They do little to help. IT actually clouds the process because you are labeling a file issue or maybe a bug as a design issue. VERY DIFFERENT DISCUSSION.

We all are in this together, rocking the boat does not get us home faster,

Blimey mate, did you ever get the wrong foot forward!

And I’ll take it that you meant to say “Arguing with the DEV, vs listening will not help you…”

Actually, no, it’s the reverse. I’m here to help, not the other way 'round. The DEV will get what THEY want further and faster by not arguing that a tester didn’t really experience what they watched happen because it couldn’t have happened.

I don’t have to be here, dude.

I’ll try to pay attention to when it happens and notice if I can what sets it up. Not much anyone can do if it’s not replicable.

I say that because I give you credit for knowing what you saw happen as you reported it.

So I factor your experience into the question.

I expect you and DEV to give me the same credit. :smiley:

He knows what has changed in his code base…
You have multiple reports that the software is working as expected.

Have you tried it with a new file created with a new template?
Either it will save the window postion and that shows the app is working with files created by the current version or it still fails on your system and the next thing to look at is why is your system not working like it is for others. Is other software interfering etc.
If it works with a fresh project, but not one you have been working on, then it is a file issue.

Now you can share the file with them as he offered above, or you can try moving your WIP to a new file and move on if interactive help is not your thing.

That is how this works. It’s a process. But stopping at step one and arguing that the program is broken vs doing basic process of elimination does not help you.

I went through the same thing with FINAL DRAFT. but have only used PAID RELEASE SOFTWARE so no excuse for corrupt files. (though life does happen)
When I load a screenplay, I am working on the CPU usage jumps and pegs at 20-25% killing my battery life.
At first, I thought it was the whole program too. Support even pretended this was normal because of spell-checking until I figured out new files of similar length didn’t run the CPU.
I created the smallest version of my file that triggered the problem and sent it to them.
They on the other hand have no not replied nor provided a fix in over a month, and retail for that software is almost $300.

I would take advantage of the great response time here and work to help them. Just some advice.