GetPrivateProfileString and WritePrivateProfileString

[Cliff Nichols]

I realize all the answers may be Null and void when it comes to VISTA, but I was wondering, if wildcards can be used with GetPrivateProfileString and WritePrivateProfileString for an INI file?

Reason I ask is that currently I use an ini file for window positions, sizes etc so the user can put things how they like it. But I also use GetWindowText to be the zSection of the ini

Tonight I was playing with a cut-off point to start the continuation of a "Never-Ending-Saga" of versions (thanx to "Scope-Creep"....or "It works like we want, BUUUUUUUTTTTT...." )

So I ran into a catch I did not think of...if the section did not exist (because the section did not match due to the new version), then the window would be 0,0 and you would not know it (unless to look for it like I did)

I just wondered if there was a wildcard?? or if I am right that I need to beef things up and make sure that I handle things correctly no matter what version it is?

(Obviously handling version differences is the "Correct way" but I also wanted to build in for situations that till tonight I did not notice (nor has the user notified me) that there is a problem with previous versions.

[Michael Mattias]

There's no such thing as wildcards.

However, WritePrivateProfileString will create the section as well as the key if it does not exist.

Also, you can get all the keys in a section as an array (small a) of null-terminated strings with GetPrivateProfileSection.

There are no Windows version differences in these functions. However, you can't write to your INI file if it's in a protected folder with UAC enabled. .. eg Program Files/MyApplication

But - once again - it is your lucky day... there are some handy-dandy functions to put that INI file in the UAC-approved place right here: Move That INI File! and Get That Ini File Name!

[Kev Peel]

See the lpDefault parameter of GetPrivateProfileString, the string passed as this parameter will be returned in the buffer if the actual INI key value doesn't exist.

[Cliff Nichols]

Kev, that may be it...I have to research closer

MCM...thanx for the link, I could not find it when I KNEEEEWWWwwww it existed, but searches would not show. (I need to plan this for VISTA sooner than I had hoped because of the end of the month, no more XP)

Since no wildcards...I have to rethink my 1st protection plan.

My 1st plan was

1. Check if INI file exists??? (if it does, use it, if it does not, then must be 1st time run, and run the wizard to set things up properly)
2. If the INI exists, then added functionality to allow users to keep windows where they last left them so they feel comfortable with the program

Since I have been trying more and more each generation to NOT have any dependencies (Installers, registries, previous versions, etc...etc), and PB gave me a MEGA-JUMP on that idea.

One thing I had not thought of, was minor details in differences in files. For example if a prior version had an entry like

[Program Name (version 1.0.0)]

And the new version is 1.0.1, and the user did not delete the INI file (why would they??? unless they wanted to run the whole setup again)...I did not even think of this situation....(Bad Cliff....Bad)

Thanx for the help...now I know its a matter of my cleaning up my thought process, and correcting "details" such as this.

I just wondered if wildcards existed to fix for previous versions that are "out in the wild" and obviously I can not go back and correct a version that someone else already has

[Michael Mattias]

Basically you need to think about what might be added in versions 1.1 and 1.2 BEFORE you put 1.0 in the field.

Oh, and you need to think about how you will upgrade existing users from 1.0 to 1.1, also BEFORE you put 1.0 in the field.

Amazing sometimes how much easier it is when you actually think about these things in advance.

MCM

[Cliff Nichols]

Basically you need to think about what might be added in versions 1.1 and 1.2 BEFORE you put 1.0 in the field.

In part I agree, but you can not fully plan for the future because you either are not knowledged in an area, or the technology does not exist yet

Oh, and you need to think about how you will upgrade existing users from 1.0 to 1.1, also BEFORE you put 1.0 in the field.

Yep thought of that, tried several different ideas, until I settled on "Who needs 3rd party installers", for "What needs no registries, nor setup" to work.
(Hopefully even just a step or 2 away from no INI files needed either) :shhh:

Amazing sometimes how much easier it is when you actually think about these things in advance.

Ain't "20-20 hindsight great???"
It really does take a "Monday Morning Quarterback" to call the plays in the game and get the game right the 1st time

[Gösta H. Lovgren-2]

Basically you need to think about what might be added in versions 1.1 and 1.2 BEFORE you put 1.0 in the field.

Oh, and you need to think about how you will upgrade existing users from 1.0 to 1.1, also BEFORE you put 1.0 in the field.

Just an observation. If one *knew* what was going to be in 1.1 or 1.2 *before* he issued 1.0, wouldn't he put it put it in 1.0 in the first place?

========================================================
"It ain't what they call you, it's what you answer to."
W. C. Fields
========================================================

[Michael Mattias]

If one *knew* what was going to be in 1.1 or 1.2 *before* he issued 1.0, wouldn't he put it put it in 1.0 in the first place?

I certainly don't. When I lock in the new features list for an upcoming release of PPPS or EDI Pal, they are locked in.

However, whilst I am programming the new features, they invariably give me ideas for the NEXT (or next after that) release. I write those down on my new feature suggestions list, and keep them in mind while finalizing the code for the current new release.

MCM

[Cliff Nichols]

I lock in the new features list for an upcoming release of...<Insert program>

However, whilst I am programming the new features, they invariably give me ideas for the NEXT (or next after that) release.

I do too...but that can not account for 2 generations back over something I did not think of back then

new feature suggestions list

Never ending list...but a lot are worth-while (Given time to implement them that is)

Anyways...answer is...(adjust code for the ole' and plan for the new) then

[Michael Mattias]

The real key to maintainable software is recognizing on day one that the software is likely to change, and writing it for maintenance: many small procedures versus putting everything 'in line'; making those procedures rely on stack-based (parameter) data rather than GLOBAL or STATIC variables, avoiding in-line literals ("magic numbers"), etc.

I use a rule that it will cost an extra ten (10) percent to create software with these attributes versus a 'quick and dirty' implementation; and you get your investment back with a profit the very first time you have to make an upgrade.