 |
 |
 |
 |
Preferences And Profiles
First Title
The Application stores in HKEY_LOCAL_MACHINE those items that are machine wide, such as port, server, directconnect and citrix These laws are passed from the ets.exe gui to the etsapi.dll api. The design was that c:\ets\api would be public virtual classes which could use the MFC c:\ets\api\apisystem is kind of a protected level within a class, use MFC if you want c:\ets\api\apisystem\midlayer really should be written in vanilla c++ to be very portable. In strict model terms your socket code breaks this rule, but as you were probably aware this class (and actually this class alone) broke that rule to start with. Thus the registry within the model is really something the api should not know exists. The Application reads HKEY_LOCAL_MACHINE at start time to tell the api what rules are applicable =================================================================================== The program ets.cpp is the start point of the application that checks the existance of all the user choices known as preferences and these as defaults are stored in the registry under HKEY_CURRENT_USER. The application then compares the registry keys of HKEY_CURRENT_USER with the structured storage keys in the file John Doe.prf Adding by enumeration from the registy to the file on a one time only basis. Both the registry and the PReFerence file are date stamped, this allows us to change a registry default and force it into the PRF file. Note once a choice key has been defined in the PRF file it is changed independantly of the registry defaults. There is an obvious gotya with all this, you cannot get a user preference until the user has logged in. To that end the password dialog is slightly out of step as it uses values previously saved in the registry as neccessary or as a reasonable guess from a load of the previous PRF file. The methods from the PRF file are overloaded in CPersistDoc for reading and writing to the structured storage file. ==================================================================================== We have an unfortunate back to front name conflict with all this. The view Windows that you open and save in Profile Files (*.PRO) the users think of as their Preferences. (ugg as the program sees HKEY_CURRENT_USER read into *.PRF once as the Preferences) PRF files are basically user replacements for registry stored defaults. Additionally PRF files contain the Accounts that Traders use on a regular basis. Traders do not have accounts. clearers and the like downloaded so they have to go somewhere locally. PRO files are the window selections created by users. These can be copied around between users as they are not specific in the way a PRF file is actually specific to an ETS id (qav, cc0, etc) PRO files are serialized objects of frames, grids and our ETSObjects such as CGUIContract, CDeliveryMonth(list) If working 100% properly and you have created PROfiles properly you never need use File New again, note a depth view can be created from a market right mouse menu ... You can within PReFerences select a PROfile to be loaded when you start the application. Every user has a PRF file per id used but not all users have a PRO file. Some users have many different PRO files for different needs at different times. A smart 'fct' user would have market based profiles for when they are trading and trade based profiles for when they are allocating or clearing. ====================================================================================== In short LOCAL_MACHINE reg is for the api CURRENT_USER reg is default settings for User Preferences see (User Accounts and View Preferences) PROfiles are stored views for future recall at any time and can be used by any user.
| |
|
|
|
 |