Jump to content

Paint.NET window location erratic


RpD

Recommended Posts

(Similar to post about 'Window locations not persistent'.

New post, since nobody moved old one for me >;} )

 

 

(I've done PC/network/CADD support for a living, so I have some experience with PC's.)

 

As long as I can remember using Paint.NET, the main window has not kept a persistent location for me... but the Colors andTools windows do maintain locations after closing the program.

 

Editing the registry doesn't appear to help, deleting the Paint.Net branch doesn't help.  Even if I don't move the main window, the re-opening location will not use the Left, Top coords from shutdown.  For some reason, the size of the main window is most often kept... but it seems not always (rare). 

 

I'm on Windows 8 now... before you say it's not supported, this problem existed on Windows 7 and on different machines if I remember correctly.

 

I have no idea why it moves around, or... how to lock it down.  Often the re-opened window seems to rest along the bottom of my screen and not necessarily in the middle... however, if maximized, it will remember that it is maximized.

 

What does Paint.NET do differently when to read/generate the Top, Left coordinates for opening the main window from the registry, that's different from reading the coordinates for Colors and Tools windows???

 

NO other programs that I run have a problem retaining their window locations.

This is simply tiresome to keep moving the main window after it opens, because it's usually showing up -under- the Colors and Tools windows which I have placed off to the right side of the main window (when it's where I want to place/size it).

(My current Toshiba notebook has the Intel HD Graphics 3000 display adapter, not an ATI/Hydravision or whatever. Paint.NET version is 3.5.10. I use an external HDTV for a monitor, but it apparently doesn't make a difference if I switch to my notebook's panel only.)

 

   I can refresh the registry (regedit) and see the "Left" and "Top" coordinates change, with each closure of Paint.NET. It seems to properly record the coordinates at the time of Paint.NET's closure... but it will -not- open again to those coordinates.  It also seems to like some congruity at re-open... because closing coordinates pairs will oftentimes be the same number... at times, Left and Top can both equal 26 or 52 or 78....hmmm, multiples of 26.  

   Other times, they may be recorded as (Left, Top) 130, 120 or 182, 120... although I do not move the window. (I currently have a main window size of 1086 by 648... monitor resolution is at 1366 x 768 ...so that makes the frequent Top coordinate of 120 + window Height equal to screen res height.)  

    Paint.NET just reopens in different locations. I've simply opened it and closed it several times to watch how Paint.NET records the closing coordinates... which usually change each time, since it opens differently each time.  (And the Paint.NET main window resides entirely onscreen.)

-- For a test, I have moved the window to an extreme location... such as having the left/top corner of the main window way offscreen to the left, and down within about a quarter inch of screen bottom (by holding the window by the title bar to move it).  On closure, doing a refresh of regedit display shows the coordinate Left as a large negative, and the coordinate Top as a large positive value, as expected.

 

Is there some analysis you can do of Paint.NET's fetch of registry Top, Left coordinates to see why it might not use them on some systems (like mine)?

 

Link to comment
Share on other sites

It's not just you fighting with this issue.

 

What works for me (W7 Mult-window environment + ATI ;-): Start Paint.NET w/o an image as parameter.

This way I'm getting the last saved window location and size.

midoras signature.gif

Link to comment
Share on other sites

"without an image" ...  Ahhh, I'd forgotten something. 

Yes, opening just the Paintdotnet.exe command remembers the main window location.

 

First, often I've been using the right-click "Open with" to open an image with Paint.NET.

I would think that's a basic and popular method of opening graphics, that should be addressed.

 

Second, I modified my Paint.NET shortcut, to include loading a blank 'JPEG.jpg', so that I could work around another limitation of Paint.NET... that of devotion to the PNG format, with no 'preferences' available to set JPG as default format.

( It seems there are no 'preferences'... or 'options'... or 'settings' ...now that I look for them again ???)

 

So we can't set a default image format... and we can't open Paint.NET with an image without the main window jumping all around.

 

I wonder if there's a way to make a macro... call Paint.NET to open fully, then feed it the right-clicked file, defaulting to my blank JPEG.jpg if I use the shortcut...  sigh.

 

I was hoping my post would prompt the developer to investigate his code (or respond here ;)... hmmm?

 

Things like this are why I use multiple graphics programs.

(Paint.NET for... ease of use(?) perhaps. IrfanView for opening speed and 'color corrections' gamma adjust; Gimp for the resynth, gimp animation plugins.)

IrfanView has some resistant quirks too... default Save As, instead of Save, for one. Save As always opens to save... somewhere other than where I opened the file I'm working on.  A single instance of a generic.bak file would suffice to prevent most Save, without prompt, accidents.

Wonder if all graphics people are... a bit set in their ways. >;}

Edited by RpD
Link to comment
Share on other sites

I have managed to resolve starting Paint.NET, with the previous window position/size, and with a blank default file... such that I can Save As... in that file's format, without having to constantly pick the filetype when it's not a .PNG.  Done using a .bat file, and a couple/three free simple .vbs files to stuff keys/filename to the Paint.NET window.  I can even 'Open with' and choose a similar .bat file for that purpose, although Windows 8 caused me some tribulations, so I'm not sure how the result runs on earlier versions. And it's tied to v3.5.10 of Paint.NET, thanks to that version number being in the Paint.NET window title. Sigh.  ('Follow'ing this topic.)

Edited by RpD
Link to comment
Share on other sites

If you are experienced you may also write a hook function for the Windows WindowManager.

 

Or use one of the existing tools like: http://www.desksoft.com/WindowManager.htm

 

WindowManager helps you to improve your work flow by remembering and
restoring the position and size of your programs and windows. Many
programs don't remember
their position and size between sessions and even Windows explorer does
not always restore windows to their last position. This is where
WindowManager steps
in and makes sure your windows are placed exactly where you want them
every time you open them. WindowManager even allows you to lock the
position and size
of any window, so that it will always open at the same spot no matter
where you move it. The window handling is fully customizable and you can
set up
special rules for your favorite or most frequently used windows. With
WindowManager, you can also minimize any window to the system tray area.

 

There is also a free version via trialpay.com

midoras signature.gif

Link to comment
Share on other sites

Well... don't really care for TrialPay.  Since Paint.NET is the only program giving me a window problem, I'd rather not load another program just to deal with that.  By Windows WindowManager, do you mean the DWM developer's tool?

 
Easier for me just to use the few simple vbs scripts and a bat file ;)... it's a little temperamental with multiple windows it seems, but good for now until I tinker some more.

Link to comment
Share on other sites

 By Windows WindowManager, do you mean the DWM developer's tool?

 

Hooking is an old concept provided by Microsoft in the WindowManager. Not so easy to use in a managed environment like Paint.NET but it should work. See SetWindowsHookEx(WH_CALLWNDPROC,..).

midoras signature.gif

Link to comment
Share on other sites

For those having an issue with this. There is a plugin link removed by Rick -- see comments below

 

post-79572-0-70827900-1368471933_thumb.j

midoras signature.gif

Link to comment
Share on other sites

midora, effect plugins that aren't actually effects are not permitted to be published on or linked from this forum (there are some exceptions). That plugin is certainly not an effect, and it does a lot of window hooking and digs itself deep into Paint.NET in ways that are not permitted (reflection, hooking events onto MainForm, etc.). I appreciate the idea and the ingenuity (and the name is awesome), but it needs to be external to Paint.NET if you're doing something like that.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

Rick no issue. Its for sure no effect but there is no other way than using effect plugins to provide a user interface.

The plugin is just a temporary fix for something I would expect that you will change in a future version of Paint.NET.

The solution is quite clean because its just managed code (no unmanaged hooking). At least much better than to use any external solution to fix the issue. I'm not complaining, just giving an explanation. I would allow the plugin as an exception.

 

At the end all the devlopers here just like to support the community. And some positive feedback is (hopefully) what we are getting for. I take your comment as positive.

 

So if you like the name, why not keeping it and just removing the link? ;-)

midoras signature.gif

Link to comment
Share on other sites

Since I get a summary notice of replies, I have the plugin name, yet Google is not divulging much of relevance based just upon that name.

 

And, uhm... since the graphic is still there in post, the name is visible in the window title bar, yes?  (oops.)

 

>> "The plugin is just a temporary fix for something I would expect that you will change in a future version of Paint.NET."

 

An expectation that may not be borne out when the developer only comments to ban a possible faux pas, but not on the OP's topic. >;}

(Sorry :snow: ... non-acknowledgment leads to conclusion of little else, even though unsubstantiated. Being ignored is so... disappointing.)
Since y'all have a bigger issue ongoing now, I'll butt out with my flippant observations.

Link to comment
Share on other sites

No direct response from the developer does not mean that is is out of view. The issue is a little bit disturbing for some of us, but from my point of view working on Paint.NET 4.0 makes more people happy...

  • Upvote 1

midoras signature.gif

Link to comment
Share on other sites

The plugin is just a temporary fix for something I would expect that you will change in a future version of Paint.NET.

midora, Your plugin isn't doing anything that Paint.NET isn't already doing. Sadly, I suspect it won't fix RpD's issue (but I certainly won't be mad if it does, a fix is a fix!). And by this I mean there doesn't appear to be any possible change to Paint.NET's code here. It's not doing anything weird in the way it saves and restores window state. In other words, I have no plans to make any code changes to Paint.NET because of what 1 person is having trouble with, especially if I can't reproduce the issue.

 

RpD, I honestly have no idea what's causing this issue on your systems. It's worked just fine for me on various systems over the last 10 years, with 1 to 4 monitors per system. Never had trouble. The ultimate way to solve this is to start with a fresh install of Windows, see if it happens. Then add one or two of your other usual programs at a time, retry loading up Paint.NET, and stop when you figure out which other app is causing the problem. This is just some simple scientific method, and it's not necessarily a practical one ("start with a fresh install of Windows"), but since you're the only one reporting this issue I must come to the hypothesis that there's something about your system other than Paint.NET that's causing this.

 

 

non-acknowledgment leads to conclusion of little else, even though unsubstantiated. Being ignored is so... disappointing.

Just because you get grumpy about it doesn't mean I'm going to swoop in with some magical fix. You're the only one who's ever reported having trouble with this, and if I knew the answer I would've replied with it. I can't possibly spend tons of time with everyone who sends me an e-mail or writes a post on the forum, so stop acting like you're privileged in some way or that it means anything.

 

And who knows, maybe the problem will go away in 4.0. The big difference between 3.5 and 4.0 in this area is that 3.5 will set the location and size in 2 steps, whereas 4.0 sets them in 1 step. (3.5 sets the Location property and then Size, whereas 4.0 sets the Bounds property which does both in 1 go)

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

Something like this is happening to me too. Windows 8 Pro 64-bit with Media Center.

 

If I close the main window on monitor #2, opening Paint.NET from Start Screen or the taskbar, Paint.NET opens where I left it in monitor #2. Or where I left it in monitor #1.

If I open Paint.NET by right clicking a pic and going via Open With, it will open in monitor #1. Even if I had it maximized in monitor #2, it will open maximized in monitor #1.

And if the window wasn't maximized, it will open in a random point in monitor #1, so far never opening in monitor #2.

 

I can do screen captures of this behavior easily.

 

http://www.youtube.com/watch?v=OcCU_2NHz0Y&feature=youtu.be

Edited by Zagna

sig.jpg.7f312affa740bae49243c4439bc4a244.jpg

Link to comment
Share on other sites

Ok, thanks for addressing my post directly  :)

 

[Edit: BY THE WAY... I have no conception of being 'privileged'. It is the reader who infers such, not the writer implying such... although I guess acknowledgment is a privilege, eh?]

 

I have to say though, that I HAVE seen another post about this problem (I believe I mentioned the previous post in OP)... not to mention that midori seems to have some experience with it...  so... I'm not "the only one". So maybe there's only three of us (now a fourth above) posting about this, but we all know there are many who don't come to post at all.

 

Grumpy I was, but politely so... usually I go to support forums and do get a response, but yes, sometimes only from other users... more when it's how to do something... not when it's some kind of fluke, quirk, or yes, bug, with the program itself that other users can't fix. It could just be some Windows routines quirk too... maybe a timing issue. The fact that it only manifests itself when a filespec is specified on the command line, or Open with... says something.  Something causes the main window to not use the previously stored coords... at times. It is difficult when the problem won't reproduce.  But a simple "I don't know what to say, I can't reproduce the problem" can be unpleasant, but sufficient acknowledgment... along with a "I'll keep that in mind for the next version" exit. It's nice to be acknowledged (esp. since having been read), without getting 'grumpy'.

 

And I have done PC support/CAD tech work for years, so I know how to 'scientfically' troubleshoot a problem... in obsessive, meticulous isolation of anything I have the slightest intuition may cause on effect on the problem.  And sometimes it's things that you would have no idea was causing such effect... I have isolated such quirks.  And you may notice my initial post goes into some meticulous detail of reiterations analyzing what I can see without looking at the code itself.

 

Again, this is the only program that does this to me. 
And I have seen it on more than one machine and O.S. -version-.

Do I have the magical mix of some offbeat add-on or utility that conflicts with P.NET?   Maybe but I doubt it. My experience guides me to use tried-and-true tools with the fewest quirks/conflicts and run the simplest of them and not some arcane, or deep-hooked, or swiss-army-knife suite of junk that burdens my system.  I don't run lean, but I run light, usually... and try to help isolate glitches with... excessive detail posts.

 

As you say, maybe v4 will automagically fix the problem.  It's not 'big' as glitches go, but it's aggravating to adjust at every start.  As I said, I start with my Paint.NET shortcut command line opening an explicitly named blank JPG file, so that I'm not constantly, aggravatingly having to switch the Save As 'filetype' away from PNG.  A nice format I'm sure, but for broadest compatibility, I use JPG, since that's the format I get, most often.  No, I'm not a profuse user of additional/advance graphics features, but I use enough to find more than one program for different advantages.  And not being able to set a file format preference is... an aggravation, as is a window that constantly moves around.  I have to believe there IS something different about how you set the main window position since my Tools, Colors, etc, Paint.NET windows -never- move around... unless -I- move them.

 

And as mentioned, I now have a .bat file, and a few one-line .vbs file to help me start Paint.NET 'plain vanilla' (no file spec), and then stuff keystrokes/jpg filename into the Paint.NET window so I can get the main window to 'behave' as well as a jpg file semi-default. Of course, you're free to set your program's default. Paint Shop Pro had the .psp format default (imagine that). And a preferences setting.

 

We devote our support time where it makes sense to ourselves, sometimes which may not coincide with our users.

As you said, I could 'start fresh'... but that's not where I want to spend my time, nor to simply prove "I'm right".

I can however, try 'safe mode' or (more involved) some VMware setup, but... my bat/vbs files workaround suffices for the moment.

Good luck, all.

Edited by RpD
Link to comment
Share on other sites

Just to say I wouldn't have metioned the fix if this issue wouldn't exist in all of my multi-monitor environments. And it solved my issue.

Maybe there is an issue with the catch of the rectangle (Screen.FromRectangle ?).

 

The video of Zagna demonstrates the effect quite good.

 

As I said earlier I would not spend time now. Let's check this again in 4.0.

 

If you like to get ideas about how to handle different screen configurations and anchor placement of effect dialogs then check version 1.1 of the fix.

midoras signature.gif

Link to comment
Share on other sites

  • 4 months later...
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...