Saving & Restoring User Info on Forms

From the little vba that i know, if you want to save form/user information you have three choices: text file, database, or the registry.

I'd like to streamline my 'save' & 'get' functions...

I'm not too swift with writing to text files, so i typically use a db & tables.


Here's a little snipet of code that i use:
' get login name
strLoginName = UCase(ThisDrawing.GetVariable("loginname"))

'if there is at least one record
If Not oRS.EOF Then
retry:
With oRS
' search for matching login name
.Index = "PrimaryKey"
.Seek "=", strLoginName
' if we find a match, edit the fields
If .NoMatch = False Then
.Edit
Else
.AddNew
End If

!txtUser = strLoginName
!txtProject = strProjectName
!txtSanLatLayer = Me.cboLayerSanitary.Value
!txtWtrLatLayer = Me.cboLayerWater.Value
!txtStmLatLayer = Me.cboLayerStorm.Value
.Update
End With
Else
With oRS
.AddNew
!txtUser = strLoginName
.Update
End With
GoTo retry
End If ' EOF
oRS.Close
oDB.Close

 

Have a look in the VBA help at GetSetting & SaveSetting for an easy way to store data in the registry.
Regards - Nathan

 

Thanks Nathan. I've never checked out the GS and SS methods. It appears that using the reg is good for a few form variables and is much more straightforwad than writing to a db.
It seems there are some instances where a table/query still has to be used (acad doesn't sort the layer collection, so if i want to present it sorted, the only way i've found to do so is write to a table and populate the control from a query based on the newly created/populated table. This is REAL pain, considering it could easily be part of the collection (an optional "sort=true" would save us a lot of coding. ))

 

Hi,

GetSettings and SaveSettings save the data under the Current User and as
such are not helpful on computers used by multiple users.

Download the RegObj.DLL from the MS web site and this will allow you to
read/write to the Local Machine area. (The IT Department may not like this,
but it does make your code much more useable.

I assemble my settings into a comma separated String and save to the:

HKLM\Software\CADApps\ProgramData key with a String value such as:
"AustRoads" holding data like 30,10,3,15,3,50,35,50
I read this data to a string and then use
dim vData as Variant
vData = Split(string, ",")
and then write the data from vData to the text boxes.

If you were to be highly consistent and create your text boxes in the
correct order, you could write code like:
(This was just typed here - not tested)

Function PopulateTextBoxes (frmForm as Form)
Dim i as Integer
dim sString as String
dim vData as Variant
sString = Read it from registry
If len (sString) = 0 then
Msgbox "Whatever"
Exit function
End if
vData = Split(string, ",")
On Error Goto AllBoxesWritten
frmForm.TextBox1 = vData(i)
i = i + 1
frmForm.TextBox2 = vData(i)
i = i + 1
frmForm.TextBox3 = vData(i)
i = i + 1
frmForm.TextBox4 = vData(i)

etc for as many text boxes as you think you are likely to have to deal with

AllBoxesWritten:
End Function

and

Function ReadTextBoxes (frmForm as Form)
Dim i as Integer
dim sString as String
sString = Read it from registry

On Error Goto AllBoxesRead
sString = frmForm.TextBox1
sString = sString & "," & frmForm.TextBox2
sString = sString & "," & frmForm.TextBox3
sString = sString & "," & frmForm.TextBox4
etc for as many text boxes as you think you are likely to have to deal with

AllBoxesRead:
err.clear
On Error Resume Next
Write sString to registry
If err <> 0
Msgbox "No data saved, Do you have permission to write to registry?"
End if
End Function

I'm not sure how elegant this code is, but it's easy to understand and high
re-useable
--


Laurie Comerford
CADApps
www.cadapps.com.au

that using the reg is good for a few form variables and is much more
straightforwad than writing to a db.

(acad doesn't sort the layer collection, so if i want to present it sorted,
the only way i've found to do so is write to a table and populate the
control from a query based on the newly created/populated table. This is
REAL pain, considering it could easily be part of the collection (an
optional "sort=true" would save us a lot of coding. ))

 

"Laurie Comerford" wrote

I don't see why. If each user has their own login and
home folder, then they also have their own user hive
in the registry.

 

Hi Tony,

They certainly do, but the data is not readily shareable.

The change came from client requests after we originally installed and
stored our licence files in the Current User area.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

I would agree with Tony in that in this case where information is being stored purely to fill a form with previous data that it would make sense for it to be user specific.
Regards - Nathan

 

Hi Nathan,

It depends entirely on the nature of the data. As I said, we were requested
to put our licence data there and the nature of the data we store is such
that it should be available to all users.

--


Laurie Comerford
CADApps
www.cadapps.com.au

stored purely to fill a form with previous data that it would make sense for
it to be user specific.

 

Sorry, but I'm getting more and more confused here.

Are we talking about your license files, or the data that
the original poster wants to store, for each user?

 

If its shareable, then it isn't user-specific data. So, where
it belongs would depend entirely on whether the data is
shared, or user-specific.

If it is user-specific data, it belongs in the user hive
(HKEY_CURRENT_USER). If the data is shared by many
users, it belongs in the system hive (HKEY_LOCAL_MACHINE).

The same applies to data stored in files (user-specific data
goes in each user's home directory structure, while shared
data can be in the Program Files/Common Files folder, or
any other location that's accessable to any user.

 

Hi Tony,

I'm sorry for my lack of clarity:

Let me reiterate:

The need to use HKLM for the licence data was requested by our clients.
Many of them have users who share computers on an availability basis and
they found it highly inconvenient having to setup the licencing for every
user on every computer due to our initial licensing system relying on data
in HKCU.

Having investigated and created a method for putting data in HKLM, it was
also sensible for the settings data associated with our programs be
available to all users, rather than having the company create it for each
user by doing multiple installations and then modifying each set of settings
data from our defaults for the settings, to match the company requirements.

This data is user adjustable and can be added to by users. If an individual
user develops additional data, then it is highly desirable that this data
also is available to the co-workers.

Hence for us, HKLM is the way to go.

Obviously there are other types of data which are user specific, but they
don't apply in our case.

If you are still confused, please let me know and I'll try again.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

Sorry, I thought we were discussing the
circumstances of the original poster, which
seem to suggest that the data is user-
specific, as opposed to shared.

I understand your circumstances (with your
licensing data), but with regards to user-
specific settings and data, I don't believe
this is applicable:

Shared and user-specific data are mutually exclusive.
So, if the original poster is saving user-specific data, I
don't see what the problem is with using the two
aforementioned functions (other than that they do not
offer very much flexibility, but that's another kettle of
fish).

 

Laurie,

I wish, for lots of IT manager's sakes, that you would reconsider _some_ of
your approach. The rest of my comment is based on the IT perspective.

I don't mind being forced to do an _initial_ install as an Admin, so that
some information will get placed in HKLM.
All my users are now defined as Limited users in WinXP. This helps me keep
the idiots... I mean, users... from installing Gator and Kazaa and
Latest_ScuzWare_From_Really_Cool_Toolbar_Vendor_of_the_Day.
This means that all my users would *not* be able to run your programs. This
is a bad thing, would not you agree?
To force company standards, sure, place data in HKLM, but make an Admin
login the one to edit the changes. If any plain-Jane user can edit it, what
good is it as a "standard"?
Copy the differential data from HKLM to HKCU and use *that* hive for user
support and custom settings.

--
R. Robert Bell


Hi Tony,

I'm sorry for my lack of clarity:

Let me reiterate:

The need to use HKLM for the licence data was requested by our clients.
Many of them have users who share computers on an availability basis and
they found it highly inconvenient having to setup the licencing for every
user on every computer due to our initial licensing system relying on data
in HKCU.

Having investigated and created a method for putting data in HKLM, it was
also sensible for the settings data associated with our programs be
available to all users, rather than having the company create it for each
user by doing multiple installations and then modifying each set of settings
data from our defaults for the settings, to match the company requirements.

This data is user adjustable and can be added to by users. If an individual
user develops additional data, then it is highly desirable that this data
also is available to the co-workers.

Hence for us, HKLM is the way to go.

Obviously there are other types of data which are user specific, but they
don't apply in our case.

If you are still confused, please let me know and I'll try again.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

Hi Robert,

In general I agree with your comments and would like to think I could make
it work that way.

However, the situation is not black and white and is dependent on the nature
of the data we are dealing with.

Any one of a number of users in the system may create data which is not user
specific, but company useable and relatively stable, but not necessarily.
If the user is unable to make that data available via the registry, it means
that each user has to recreate it, or there has to be a human system in
place where the user Emails the IT and says "Please do this".

I have no solution to this problem, but in the absence of a client
complaint, have not needed to resolve it. Practical suggestions are
welcome.

At this stage, I don't really want to go back to writing the data to a file.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

I understand... "If it ain't broke, don't fix it." I know that storing data
in an external file might not be ideal in your circumstance.

Personally, one of my tests for "professional software" is if it will run
under a limited/restricted user. Unhappily, it seems that most design
software is written without regard to this criteria.

--
R. Robert Bell


Hi Robert,

In general I agree with your comments and would like to think I could make
it work that way.

However, the situation is not black and white and is dependent on the nature
of the data we are dealing with.

Any one of a number of users in the system may create data which is not user
specific, but company useable and relatively stable, but not necessarily.
If the user is unable to make that data available via the registry, it means
that each user has to recreate it, or there has to be a human system in
place where the user Emails the IT and says "Please do this".

I have no solution to this problem, but in the absence of a client
complaint, have not needed to resolve it. Practical suggestions are
welcome.

At this stage, I don't really want to go back to writing the data to a file.

--


Laurie Comerford
CADApps
www.cadapps.com.au

 

I agree.
Registry should hold general options and personal
settings plus default values. A standard user should
be able to run the software without problems.
Installation may require admin, to set some special
registry values, but that should be it.

Software that writes usable company data to the registry
is also hard to move to a new computer.
This sort of data should be placed in a file or database
in the user's document or the common files dir
depending on the type and the intended use of the data.

 

Like Tony I thought we were discussing the original posters circumstances. If you read the original post it should be clear that Oberor was aready specifically storing the data for each user.

Regards - Nathan

 

In my opinion, writing to the Window's registry exemplifies what is wrong with that OS. Our IT folks wisely keep us from altering it. For what it is worth, the following crude and brute force method of using a text file to save a form's state is easy to manage, fast, easily adapted, and has always worked for me. These are the main componants from a project:

Sub GetPrefs()
Dim MacroPref As String
Dim x As Integer
Dim stat As Integer
On Error GoTo skip
'MacroPref = Preferences.Files.TempFilePath & PrefData
MacroPref = PrefPath & PrefData
Open MacroPref For Input As #1
Do While Not EOF(1) ' Loop until end of file.
Input #1, Line
Select Case Left(Line, 3)
Case Is = "fx:" ' dialog left
DlgLeft = Right(Line, Len(Line) - 3)
Case Is = "fy:" ' dialog top
DlgTop = Right(Line, Len(Line) - 3)
Case Is = "rs:" ' resolution
Res = Val(Right(Line, Len(Line) - 3))
Case Is = "la:" ' resolution
HidLayer = Right(Line, Len(Line) - 3)
Case Is = "lt:" ' resolution
HidLinType = Right(Line, Len(Line) - 3)
Case Is = "co:" ' resolution
HidColor = Right(Line, Len(Line) - 3)
Case Is = "gd:" ' gap distance
GapDist = Val(Right(Line, Len(Line) - 3))
Case Is = "ug:" ' use gap distance
UseGap = Right(Line, Len(Line) - 3)
Case Is = "ul:" ' use layer
UseLay = Right(Line, Len(Line) - 3)
Case Is = "ut:" ' use linetype
UseLineT = Right(Line, Len(Line) - 3)
Case Is = "uc:" ' use color
UseColor = Right(Line, Len(Line) - 3)
Case Is = "kt:" ' keep trucking
KeepTruckn = Right(Line, Len(Line) - 3)
Case Is = "tm:" ' Trim mode
TrimMode = Right(Line, Len(Line) - 3)
Case Is = "im:" ' Int mode
IntMode = Right(Line, Len(Line) - 3)
End Select
Loop
Close #1 ' Close file.
skip:
On Error GoTo 0
End Sub

Private Sub SavePrefs()
Dim MacroPref As String
Dim x As Integer
On Error GoTo skip
'MacroPref = Preferences.Files.TempFilePath & PrefData
MacroPref = PrefPath & PrefData
Close #1
Open MacroPref For Output As #1
Print #1, "This is the BREAK2HIDDEN.DVB preferences file. " & Issue
On Error GoTo skip
Print #1, "fy:"; DlgTop
Print #1, "fx:"; DlgLeft
Print #1, "rs:"; Res ' default resolution
Print #1, "la:"; HidLayer ' default layer
Print #1, "lt:"; HidLinType ' default linetype
Print #1, "co:"; HidColor ' default color
Print #1, "gd:"; GapDist ' gap distance
Print #1, "ug:"; UseGap ' use gap distance
Print #1, "ul:"; UseLay ' use layer
Print #1, "ut:"; UseLineT ' use linetype
Print #1, "uc:"; UseColor ' use color
Print #1, "kt:"; KeepTruckn ' keep trucking mode
Print #1, "tm:"; TrimMode ' trim mode
Print #1, "im:"; IntMode ' intersection mode
skip:
Close #1
On Error GoTo 0
End Sub

AKS

 

AKS wrote :
"Re: Saving & Restoring User Info on Forms
In my opinion, writing to the Window's registry exemplifies what is wrong with that OS. Our IT folks wisely keep us from altering it."

From lack of info, and not being an IT guy, this has been my opinion. I'm one of those uninformed people who think there's something "special" about the registry.
If there is, then "... exemplifies what is wrong with that OS..
" is very appropriate & true.

I had originally started this thread due to my programming ignorance. I currently store settings in a table. I think I'll stick with the db for now. Thanks for all the help and dicussion. This board is a wealth of information!

 

If you want to use files, I you might look into using the api functions for
working with ini files. This more closely parallels the .NET method of using
xml and config files. Ini files use [Section] tags and key, value pairs to
store info and is easy to use.

--
----
Ed
----

with that OS. Our IT folks wisely keep us from altering it."

one of those uninformed people who think there's something "special" about
the registry.

currently store settings in a table. I think I'll stick with the db for
now. Thanks for all the help and dicussion. This board is a wealth of
information!