How does NotePad know where to put the window?

[NadCixelsyd]

I use NotePad a lot for a text editor. I sometimes move and/or resize
the window. Whenever I start NotePad, the window is always in the
same location and size as the most recent execution of NotePad. Where
does NotePad save this information? It's nowhere near the NOTEPAD.EXE
module (or I can't see it)

I'm writing an application and I'd like that same feature: Open the
window in the previous location at the previous size. Where does
NotePad save this information so I can do something similar?

[Christian ASTOR]

NadCixelsyd a écrit :

> I use NotePad a lot for a text editor. I sometimes move and/or resize
> the window. Whenever I start NotePad, the window is always in the
> same location and size as the most recent execution of NotePad. Where
> does NotePad save this information?

HKCU\Software\Microsoft\Notepad
(GetWindowPlacement())

[Alf P. Steinbach]

Windows has a common repository of all kinds of configuration
information, called the "registry".

Just type "regedit" in the start menu.

Navigate to e.g. [HKEY_CURRENT_USER\Software\Microsoft\Notepad].


Cheers & hth.,

- Alf

[Bert Hyman]

In news:je1tfg$ehu$1...@dont-email.me "Alf P. Steinbach"

<alf.p.stein...@gmail.com> wrote:

> On 04.01.2012 16:55, NadCixelsyd wrote:
>>>
>> I'm writing an application and I'd like that same feature: Open the
>> window in the previous location at the previous size. Where does
>> NotePad save this information so I can do something similar?
>
> Windows has a common repository of all kinds of configuration
> information, called the "registry".

Or programs might store the data in

..\Documents and Settings\<user>\Local Settings\Application Data\...

That's for XP; I'm sure there's something similar but completely
different for Vista and Windows 7.

--
Bert Hyman St. Paul, MN be...@iphouse.com

[Alf P. Steinbach]

Yah, I forgot to mention. On the other hand, it did seem, on inspection,
that Notepad does store its window size in that registry key.

Anyway,


<example>
[d:\temp]
> set | find /i "data="
APPDATA=C:\Users\Alf\AppData\Roaming
LOCALAPPDATA=C:\Users\Alf\AppData\Local
ProgramData=C:\ProgramData

[d:\temp]
> _
</example>

The %LOCALAPPDATA% is most relevant.

At the API level, to bridge the XP/Vista gap see ShGetFolderPath:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx

It is in a way interesting that the documentation urges developers to
write code that will not work on XP.

However, using the registry is simple, and there there is no such issue.

At least until Microsoft artifically creates it (it would not surprise me).

Cheers & hth.,

- Alf

PS: New years greetings to all of you folks in St.Paul, Minnesota! For
some reason my brain refuses to come up with the name of the other half
of the city? But greetings that way too! :-)

[Charlie Gibbs]

In article <Xns9FD0A6BD8ED...@216.250.188.141>,

Save it anywhere you want. If you save it in the same directory
as the file you're editing, you can edit files in multiple
directories and have a separate set of saved values for each
one. You can create a save file name based on the name of the
file you're editing, and each file's values will be unique.
Or you can save the data in the same directory as the executable.
You're not required to save it in any particular place - the choice
is totally up to you. Choose whatever works best.

I wouldn't recommend the Registry for this, but I wouldn't recommend
the Registry for anything. I don't like putting all my eggs in one
basket.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Bert]

In news:1668.421T1...@kltpzyxm.invalid "Charlie Gibbs"

<cgi...@kltpzyxm.invalid> wrote:

> Save it anywhere you want.

I suspect that your users would object.

--
be...@iphouse.com St. Paul, MN

[Bob Masta]

On 04 Jan 12 11:53:28 -0800, "Charlie Gibbs"

<cgi...@kltpzyxm.invalid> wrote:

>In article <Xns9FD0A6BD8ED...@216.250.188.141>,
>be...@iphouse.com (Bert Hyman) writes:
>
>> In news:je1tfg$ehu$1...@dont-email.me "Alf P. Steinbach"
>> <alf.p.stein...@gmail.com> wrote:
>>
>>> On 04.01.2012 16:55, NadCixelsyd wrote:
>>>
>>>> I'm writing an application and I'd like that same feature: Open the
>>>> window in the previous location at the previous size. Where does
>>>> NotePad save this information so I can do something similar?
>>>
>>> Windows has a common repository of all kinds of configuration
>>> information, called the "registry".
>>
>> Or programs might store the data in
>>
>> ..\Documents and Settings\<user>\Local Settings\Application Data\...
>>
>> That's for XP; I'm sure there's something similar but completely
>> different for Vista and Windows 7.
>
>Save it anywhere you want. If you save it in the same directory
>as the file you're editing, you can edit files in multiple
>directories and have a separate set of saved values for each
>one. You can create a save file name based on the name of the
>file you're editing, and each file's values will be unique.
>Or you can save the data in the same directory as the executable.
>You're not required to save it in any particular place - the choice
>is totally up to you. Choose whatever works best.

There can be problems saving in the same directory as the
executable, if it was installed "normally" under Program
Files. One simple (though unapproved) method is to install
a subdirectory for your app under My Documents and put your
INI stuff and other aplication data there.

>I wouldn't recommend the Registry for this, but I wouldn't recommend
>the Registry for anything. I don't like putting all my eggs in one
>basket.

Agreed!

Best regards,


Bob Masta

DAQARTA v6.02
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!

[Friedel Jantzen]

Am Thu, 05 Jan 2012 13:12:12 GMT schrieb Bob Masta:
...

>
> There can be problems saving in the same directory as the
> executable, if it was installed "normally" under Program
> Files.

Yes, on Vista+ a non-admin user will not succeed in saving the settings
there: Access denied. So this is no longer an option.

Why not use the recommended places for this?
There are some APIs to get the path, e.g.:
SHGetKnownFolderIDList (Vista+):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762187%28v=vs.85%29.aspx
with FOLDERID_LocalAppData rsp. FOLDERID_ProgramData
SHGetSpecialFolderLocation (Win9x+):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762180%28v=vs.85%29.aspx
with CSIDL_LOCAL_APPDATA rsp. CSIDL_COMMON_APPDATA
SHGetFolderLocation (Win2000+):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762180%28v=vs.85%29.aspx

Regards,
Friedel

[Deanna Earley]

On 05/01/2012 13:12, Bob Masta wrote:
> One simple (though unapproved) method is to install a subdirectory
> for your app under My Documents and put your INI stuff and other
> aplication data there.

Er, no, the "My Documents" folder is exactly that, not the "Your random
program's application data" folder.

Application data should go into one of the application data folders.
http://hashvb.earlsoft.co.uk/Special_folders

--
Deanna Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

[Alf P. Steinbach]

On 06.01.2012 11:45, Deanna Earley wrote:
> On 05/01/2012 13:12, Bob Masta wrote:
>> One simple (though unapproved) method is to install a subdirectory
>> for your app under My Documents and put your INI stuff and other
>> aplication data there.
>
> Er, no, the "My Documents" folder is exactly that, not the "Your random
> program's application data" folder.
>
> Application data should go into one of the application data folders.
> http://hashvb.earlsoft.co.uk/Special_folders

I always eschew using any of the special Microsoft-provided folders for
anything of my own.

Because these folders become full of crap very fast.

And to clean up you'd have to do a fair amount of detective work.

Up until Windows 7 it was just easier to use your own folder structure,
e.g. on any new disk start by creating a root folder which Windows and
application programs won't automatically pollute.

However, with Windows 7 the shell GUI, Windows Explorer, has been
changed to display the unusuable standard (virtual) folders that get
full of crap fast, on top of the folder pane. So on a small laptop
screen you may not even see the normal folder structure, it disappears
out on the bottom of the list, which then only displays crap that I'm
not at all interested in.

It's like Microsoft want users to *have* to deal with the useless crap.

I don't understand how such decisions can have been approved. It is like
they are actively kicking users off Windows. For sure, if I had just a
little more money, I'd been using Mac, and no Windows.


Cheers,

- Alf

[Jongware]

But earlier in this thread people argued *against* using the Registry,
which, although /also/ "full of crap" at least hides all those
uninteresting settings from the user. And by using HKCU, you get
per-user-settings for free.

Any and all of the earlier methods -- stuffing it into My Documents, in
the Program Files folder, or "in the same directory as the file you're
editing" (which is something I did once and started to regret after I
edited some hundreds of files with it) -- ALL do nothing more than
increasing the problem of random software dumping random unrecognized
files on random locations all over the user's HD.

(Sure, the Registry is an unforgiving mistress and may throw the odd
tantrum now and then. But at least you know it's *supposed* to behave
that way, right, Microsoft?)

[Jw]

[Bob Masta]

On Fri, 06 Jan 2012 10:45:20 +0000, Deanna Earley
<dee.e...@icode.co.uk> wrote:

>On 05/01/2012 13:12, Bob Masta wrote:
>> One simple (though unapproved) method is to install a subdirectory
>> for your app under My Documents and put your INI stuff and other
>> aplication data there.
>
>Er, no, the "My Documents" folder is exactly that, not the "Your random
>program's application data" folder.

Some apps create documents that the user may want to access
(or copy for backup) from outside the app. The place users
expect to find these documents is under "My Documents", and
putting them in their own app-named folder there makes them
easy to find. Having an additional folder under that for
app data makes it easy to find as well.

>Application data should go into one of the application data folders.
>http://hashvb.earlsoft.co.uk/Special_folders

Users already understand how to find and deal with My
Documents. That's not usually true for special folders, in
my experience. (That's "my experience dealing with users"
and also "my experience *as* a user", since things differ on
different Windows versions.)

There can be all sorts of reasons for users to need access
to files that you might have considered to be "app data",
such as custom templates or setups that the user wants to
share with others. Keeping everything in logical,
accesssible locations saves on user frustration and on
support requests. And when you do need to explain where a
file is, the My Documents\MyApp\AppData path is easy for
them to grasp.

[Deanna Earley]

On 06/01/2012 11:02, Alf P. Steinbach wrote:
> For sure, if I had just a little more money, I'd been using Mac, and
> no Windows.

Feel free to use something even even cheaper like Linux (Seeing as
you've already said you'd happily abandon Windows)

[Deanna Earley]

On 06/01/2012 13:22, Bob Masta wrote:
> On Fri, 06 Jan 2012 10:45:20 +0000, Deanna Earley
> <dee.e...@icode.co.uk> wrote:
>
>> On 05/01/2012 13:12, Bob Masta wrote:
>>> One simple (though unapproved) method is to install a subdirectory
>>> for your app under My Documents and put your INI stuff and other
>>> aplication data there.
>>
>> Er, no, the "My Documents" folder is exactly that, not the "Your random
>> program's application data" folder.
>
> Some apps create documents that the user may want to access
> (or copy for backup) from outside the app. The place users
> expect to find these documents is under "My Documents", and
> putting them in their own app-named folder there makes them
> easy to find. Having an additional folder under that for
> app data makes it easy to find as well.

For stuff that I (as an average user) would want access to or that I
explicitly save, that's fine.
When it gets full of "My über app's window position.ini" or even "My
über app's config data that I think is so special I'm going to thrust it
in your face when looking for your own stuff\" is where it should stop.

Event worse when it is on a remote network share.

"My Documents" is for my documents. Simples.

[Bob Masta]

On Fri, 06 Jan 2012 16:29:02 +0000, Deanna Earley

<dee.e...@icode.co.uk> wrote:

>On 06/01/2012 13:22, Bob Masta wrote:
>> On Fri, 06 Jan 2012 10:45:20 +0000, Deanna Earley
>> <dee.e...@icode.co.uk> wrote:
>>
>>> On 05/01/2012 13:12, Bob Masta wrote:
>>>> One simple (though unapproved) method is to install a subdirectory
>>>> for your app under My Documents and put your INI stuff and other
>>>> aplication data there.
>>>
>>> Er, no, the "My Documents" folder is exactly that, not the "Your random
>>> program's application data" folder.
>>
>> Some apps create documents that the user may want to access
>> (or copy for backup) from outside the app. The place users
>> expect to find these documents is under "My Documents", and
>> putting them in their own app-named folder there makes them
>> easy to find. Having an additional folder under that for
>> app data makes it easy to find as well.
>
>For stuff that I (as an average user) would want access to or that I
>explicitly save, that's fine.
>When it gets full of "My über app's window position.ini" or even "My
>über app's config data that I think is so special I'm going to thrust it
>in your face when looking for your own stuff\" is where it should stop.

My point (which you cropped) was that it is not always
obvious to the developer what the "average" user will want
or need access to. Microsoft wants us to use a "Big Bother"
approach where we hide things in cryptic places to protect
the user. I'm suggesting that it doesn't have to be that
way, nor does it have to thrust any messy details in the
user's face when they are unwanted. It's not either-or.

If you put your app's "normal" documents under
My Documents - MyApp
then users can go straight to them. If they also see a
subdirectory below that, such as
My Documents - MyApp - Settings
(or whatever) they know where to look if they ever need the
geeky stuff, but it's never in their face.

But we may just have to agree to disagree on this... <g>