Hi Y'all,

Where does VX store its configuration data?

IOW, when I click File>Recent Projects where is it getting the list from?

TIA,

    >don<

AFAIK all is stored in the regestry, but that is supposed to change in 
the future.

Jim

Don Keating wrote:

> Hi Y'all,
> 
> Where does VX store its configuration data?
> 
> IOW, when I click File>Recent Projects where is it getting the list from?
> 
> TIA,
> 
>     >don<
> 
> 
> 
>

Hi Don,

As James said, it's in the registry.
Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......

But as he also said, the plan is to use database files in the future.

-Joe

"Don Keating" <DonK@dbscompany.com> wrote in message
news:vpNnBXrFEHA.3240@S15147418...
> Hi Y'all,
>
> Where does VX store its configuration data?
>
> IOW, when I click File>Recent Projects where is it getting the list from?
>
> TIA,
>
>     >don<
>
>
>
>

There are no plans to store anything in databases.

Currently persistance is reached in two ways. Project specific
things are stored in the xpj file. Thus there are some new
values that have been introduced with VX such as Breakpoints.

Other things are stored in the registry under the location
mentioned.

Our plans for the future of persistance is based on two
facts.

1) We do not like the registry.
2) We realized that the current solution to store all project
    specific information to the xpj file will make it hard to
    use the xpj file in a multi developer environment.
    E.g. information about OpenFiles is user specific.

Regards
   Andreas Herdt
   [Alaska Research & Development]

Joe Carrick - The Maniacc wrote:
> Hi Don,
> 
> As James said, it's in the registry.
> Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......
> 
> But as he also said, the plan is to use database files in the future.
> 
> -Joe
> 
> "Don Keating" <DonK@dbscompany.com> wrote in message
> news:vpNnBXrFEHA.3240@S15147418...
> 
>>Hi Y'all,
>>
>>Where does VX store its configuration data?
>>
>>IOW, when I click File>Recent Projects where is it getting the list from?
>>
>>TIA,
>>
>>    >don<
>>
>>
>>
>>
> 
>

Hi Andreas,

Sorry, I didn't mean to misrepresent your intentions.  IMO, the xpj file is
a database just like any other non-executable file.  The format of many
files just happen to be pure text - at least from the standpoint of the
user.  The computere of course sees them as bits of information represented
in binary form.

I am curious however about your statement.  Other than the actual files
required for the project and their relationships that are needed for the
compiler, what is stored in the xpj.  I have searched thru the registry for
the files that are to be opened for editing when the xpj is opened and do
not find them listed.  I have also opened the xpj with other programs and
can not find any additional information there.

Various control information (user settings) for the editor, etc are in the
registry.  So what is where?  For some of us, this information would be very
useful.  BTW, is there any reason why we couldn't substitute another editor
such as Mew32 for the VX Editor?  This IMO would be a nice option.

-Joe


"Andreas Herdt" <andreas.herdt@alaska-research.com> wrote in message
news:S48$WgyFEHA.3068@S15147418...
> There are no plans to store anything in databases.
>
> Currently persistance is reached in two ways. Project specific
> things are stored in the xpj file. Thus there are some new
> values that have been introduced with VX such as Breakpoints.
>
> Other things are stored in the registry under the location
> mentioned.
>
> Our plans for the future of persistance is based on two
> facts.
>
> 1) We do not like the registry.
> 2) We realized that the current solution to store all project
>     specific information to the xpj file will make it hard to
>     use the xpj file in a multi developer environment.
>     E.g. information about OpenFiles is user specific.
>
> --
> Regards
>    Andreas Herdt
>    [Alaska Research & Development]
>
> Joe Carrick - The Maniacc wrote:
> > Hi Don,
> >
> > As James said, it's in the registry.
> > Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......
> >
> > But as he also said, the plan is to use database files in the future.
> >
> > -Joe
> >
> > "Don Keating" <DonK@dbscompany.com> wrote in message
> > news:vpNnBXrFEHA.3240@S15147418...
> >
> >>Hi Y'all,
> >>
> >>Where does VX store its configuration data?
> >>
> >>IOW, when I click File>Recent Projects where is it getting the list
from?
> >>
> >>TIA,
> >>
> >>    >don<
> >>
> >>
> >>
> >>
> >
> >

I found the "OPENFILES" line in the xpj.

-Joe

> Our plans for the future of persistance is based on two
> facts.
>
> 1) We do not like the registry.
> 2) We realized that the current solution to store all project
>     specific information to the xpj file will make it hard to
>     use the xpj file in a multi developer environment.
>     E.g. information about OpenFiles is user specific.
>

This doesn't say what your actual plans are... so... if  I may be so bold as
to suggest some form of Application-specific storage system for Application
and User-related data, such as the now-very-old-but-it-kinda-still-works
.ini file or the likely-every-programmer-has-had-to-do-this-himself
users.dbf type of thing where data for a specific user is stored in a file
which is created automatically upon startup of any Xbase++ app.

Most, if not all of us have had to create a system of tracking users and
application data, especially on a LAN.

If this were an inherent part of the Xbase++ runtime,  you would be solving
a problem which a lot of future (we hope for many of those) Xbase++
programmers will need to solve and creating a standard for something which
already exists.

Ideally this is a startup procedure which could be replaced by our own
should we wish to do so, same as appsys or dbesys - and if we choose to do
so then we'd have to include some support for the standard developers'
information of 'OpenFiles' or 'CurrentPath' or whatever... course you'd have
a set of defines

LOCAL_SETTINGS_OPEN_FILES
1
LOCAL_SETTINGS_COLOUR_OF_TEXT_IN_EDITOR                 2
LOCAL_SETTINGS_COLOUR_OF_TEXT_IN_WARNINGS          3
    ...

LOCAL_SETTINGS_USER_DEFINED                                          400


I'm not entirely sure the integrating the development system
settings-storage with the runtime settings-storage is actually a good idea -
there is always something to be said for keeping discrete components
discrete - but it might be something to think about.

Hi Eric,

My statement was not clear enough.

The design goal for the project loader was that existing
xpj files could be used. Additionally we had to store
breakpoint and openfiles information and felt this was
project specific information and thus it is wise to store
it in the xpj file also. At this point have guaranteed that
the project still could be built by older Xbase++ versions.

In the meantime we have realized that
a) the solution is working
b) it comes to a conflict when more then one developer
    is working on the project

This is due to the fact that Project specific information
can be global (valid for all developpers) and developer
specific.

Our next step in short term will be to provide a solution
to solve this issue. The goals are:

VX can work with standard xpj files
XPJ files are valid for older Xbase++ versions
Developper specific information must not be placed to the XPJ File.

However, it should be clear that in middle/long term the
XPJ file will be substituted by a more modern mechanism
like XML Streaming.

(Yes, the migration will be smooth)

Regards
   Andreas Herdt
   [Alaska Research & Development]


Eric Breddam wrote:
>>Our plans for the future of persistance is based on two
>>facts.
>>
>>1) We do not like the registry.
>>2) We realized that the current solution to store all project
>>    specific information to the xpj file will make it hard to
>>    use the xpj file in a multi developer environment.
>>    E.g. information about OpenFiles is user specific.
>>
> 
> 
> This doesn't say what your actual plans are... so... if  I may be so bold as
> to suggest some form of Application-specific storage system for Application
> and User-related data, such as the now-very-old-but-it-kinda-still-works
> .ini file or the likely-every-programmer-has-had-to-do-this-himself
> users.dbf type of thing where data for a specific user is stored in a file
> which is created _automatically_ upon startup of any Xbase++ app.
> 
> Most, if not all of us have had to create a system of tracking users and
> application data, especially on a LAN.
> 
> If this were an inherent part of the Xbase++ runtime,  you would be solving
> a problem which a lot of future (we hope for many of those) Xbase++
> programmers will need to solve and creating a standard for something which
> already exists.
> 
> Ideally this is a startup procedure which could be replaced by our own
> should we wish to do so, same as appsys or dbesys - and if we choose to do
> so then we'd have to include some support for the standard developers'
> information of 'OpenFiles' or 'CurrentPath' or whatever... course you'd have
> a set of defines
> 
> LOCAL_SETTINGS_OPEN_FILES
> 1
> LOCAL_SETTINGS_COLOUR_OF_TEXT_IN_EDITOR                 2
> LOCAL_SETTINGS_COLOUR_OF_TEXT_IN_WARNINGS          3
>     ...
> 
> LOCAL_SETTINGS_USER_DEFINED                                          400
> 
> 
> I'm not entirely sure the integrating the development system
> settings-storage with the runtime settings-storage is actually a good idea -
> there is always something to be said for keeping discrete components
> discrete - but it might be something to think about.
> 
> 
>

Andreas,

it is my true belief that neither registry nor project file or database
are suited to meet future requirements of VX and its users.

IMHO, the way to go is XML. This file format provides all flexibility
you and your customers need for the future.

What are your plans in this direction?

Thanks for answering,

Hannes

Andreas Herdt wrote:
> 
> There are no plans to store anything in databases.
> 
> Currently persistance is reached in two ways. Project specific
> things are stored in the xpj file. Thus there are some new
> values that have been introduced with VX such as Breakpoints.
> 
> Other things are stored in the registry under the location
> mentioned.
> 
> Our plans for the future of persistance is based on two
> facts.
> 
> 1) We do not like the registry.
> 2) We realized that the current solution to store all project
>     specific information to the xpj file will make it hard to
>     use the xpj file in a multi developer environment.
>     E.g. information about OpenFiles is user specific.
> 
> --
> Regards
>    Andreas Herdt
>    [Alaska Research & Development]
> 
> Joe Carrick - The Maniacc wrote:
> > Hi Don,
> >
> > As James said, it's in the registry.
> > Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......
> >
> > But as he also said, the plan is to use database files in the future.
> >
> > -Joe
> >
> > "Don Keating" <DonK@dbscompany.com> wrote in message
> > news:vpNnBXrFEHA.3240@S15147418...
> >
> >>Hi Y'all,
> >>
> >>Where does VX store its configuration data?
> >>
> >>IOW, when I click File>Recent Projects where is it getting the list from?
> >>
> >>TIA,
> >>
> >>    >don<
> >>
> >>
> >>
> >>
> >
> >

I agree.
Practically every programmer has had to learn to deal with SDF and INI 
files and I expect the same will be true for XML.
Configuration data is an excellent, easy introduction to XML
Garry

Dr. Hannes Ziegler wrote:
> Andreas,
> 
> it is my true belief that neither registry nor project file or database
> are suited to meet future requirements of VX and its users.
> 
> IMHO, the way to go is XML. This file format provides all flexibility
> you and your customers need for the future.
> 
> What are your plans in this direction?
> 
> Thanks for answering,
> 
> Hannes
> 
> Andreas Herdt wrote:
> 
>>There are no plans to store anything in databases.
>>
>>Currently persistance is reached in two ways. Project specific
>>things are stored in the xpj file. Thus there are some new
>>values that have been introduced with VX such as Breakpoints.
>>
>>Other things are stored in the registry under the location
>>mentioned.
>>
>>Our plans for the future of persistance is based on two
>>facts.
>>
>>1) We do not like the registry.
>>2) We realized that the current solution to store all project
>>    specific information to the xpj file will make it hard to
>>    use the xpj file in a multi developer environment.
>>    E.g. information about OpenFiles is user specific.
>>
>>--
>>Regards
>>   Andreas Herdt
>>   [Alaska Research & Development]
>>
>>Joe Carrick - The Maniacc wrote:
>>
>>>Hi Don,
>>>
>>>As James said, it's in the registry.
>>>Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......
>>>
>>>But as he also said, the plan is to use database files in the future.
>>>
>>>-Joe
>>>
>>>"Don Keating" <DonK@dbscompany.com> wrote in message
>>>news:vpNnBXrFEHA.3240@S15147418...
>>>
>>>
>>>>Hi Y'all,
>>>>
>>>>Where does VX store its configuration data?
>>>>
>>>>IOW, when I click File>Recent Projects where is it getting the list from?
>>>>
>>>>TIA,
>>>>
>>>>   >don<
>>>>
>>>>
>>>>
>>>>
>>>

Hi Gary,

Please see my reply to Eric.

Regards
   Andreas Herdt
   [Alaska Research & Development]


Garry Allen wrote:

> I agree.
> Practically every programmer has had to learn to deal with SDF and INI 
> files and I expect the same will be true for XML.
> Configuration data is an excellent, easy introduction to XML
> Garry
> 
> Dr. Hannes Ziegler wrote:
> 
>> Andreas,
>>
>> it is my true belief that neither registry nor project file or database
>> are suited to meet future requirements of VX and its users.
>>
>> IMHO, the way to go is XML. This file format provides all flexibility
>> you and your customers need for the future.
>>
>> What are your plans in this direction?
>>
>> Thanks for answering,
>>
>> Hannes
>>
>> Andreas Herdt wrote:
>>
>>> There are no plans to store anything in databases.
>>>
>>> Currently persistance is reached in two ways. Project specific
>>> things are stored in the xpj file. Thus there are some new
>>> values that have been introduced with VX such as Breakpoints.
>>>
>>> Other things are stored in the registry under the location
>>> mentioned.
>>>
>>> Our plans for the future of persistance is based on two
>>> facts.
>>>
>>> 1) We do not like the registry.
>>> 2) We realized that the current solution to store all project
>>>    specific information to the xpj file will make it hard to
>>>    use the xpj file in a multi developer environment.
>>>    E.g. information about OpenFiles is user specific.
>>>
>>> -- 
>>> Regards
>>>   Andreas Herdt
>>>   [Alaska Research & Development]
>>>
>>> Joe Carrick - The Maniacc wrote:
>>>
>>>> Hi Don,
>>>>
>>>> As James said, it's in the registry.
>>>> Check HKEY_CURRENT_USER/Software/Alaska Software/ Visual Xbase++/......
>>>>
>>>> But as he also said, the plan is to use database files in the future.
>>>>
>>>> -Joe
>>>>
>>>> "Don Keating" <DonK@dbscompany.com> wrote in message
>>>> news:vpNnBXrFEHA.3240@S15147418...
>>>>
>>>>
>>>>> Hi Y'all,
>>>>>
>>>>> Where does VX store its configuration data?
>>>>>
>>>>> IOW, when I click File>Recent Projects where is it getting the list 
>>>>> from?
>>>>>
>>>>> TIA,
>>>>>
>>>>>   >don<
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>