13630Re: [Clip] Parsing INI operations
- May 10, 2005John, Harvey, Jamal, et. al.,
If the NoteTab ini file is for an open instance of NoteTab, then it is
not updated until NoteTab is closed or the ^!ProgIniSave command is
used. Then one must use ^!ProgIniLoad to read the new results from the
This will translate to other programs where the ini file is in use
because the program is open.
This is not the case if one uses a custom ini file, that is basically a
text file for saving variables for later.
This is not contrary behavior, or a big mystery that we need to consult
Eric, but what one should expect from working with a file that is in
use. This is why there is a special command to be able to edit a NoteTab
ini file in NoteTab, one must prefix its name with an "!" when saving it
to get the changes to store.
There are two ways of interacting with ini files simply because in one
way the file is in use and in the other it is like a data file. When the
file is in use, it will match what MS says about it. When the program
that uses the ini file is running, it will follow the rules from MS. If
it is an ini file for a clip, think of a specially formed text file for
I hope this clarifies the "mystery".
Kairos Computer Solutions
Sales Affiliate for Grisoft Anti-Virus
John Zeman wrote:
> That's interesting hrs, apparently if we use an ini file other than the default NotePro.ini file, NoteTab does just what you say here. However with the NotePro.ini, which is what I was testing with, NoteTab seems to behave the way I stated it last time.
> I'm starting to think Jamal is close to nailing it concerning the flushing-to-disk issue he's talking about. At least when the default NotePro.ini file is used as the ini file in a clip. Perhaps he could easily solve his problem by specifying a separate ini file as hrs does in his example?
- << Previous post in topic Next post in topic >>