Saving & Restoring User Info on Forms

Anonymous · ‎01-05-2005

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

Anonymous · ‎01-05-2005

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

Anonymous · ‎01-06-2005

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. ))

Anonymous · ‎01-06-2005

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 "Oberer" wrote in message news:[email protected]... > 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. ))

Anonymous · ‎01-06-2005

"Laurie Comerford" wrote > Hi, > > GetSettings and SaveSettings save the data under the Current User and as > such are not helpful on computers used by multiple users. > 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. -- http://www.caddzone.com AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 http://www.acadxtabs.com

Anonymous · ‎01-06-2005

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 "Tony Tanzillo" wrote in message news:41ddbec7_2@newsprd01... > "Laurie Comerford" wrote > > > Hi, > > > > GetSettings and SaveSettings save the data under the Current User and as > > such are not helpful on computers used by multiple users. > > > > 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. > > -- > http://www.caddzone.com > > AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 > http://www.acadxtabs.com > >

Anonymous · ‎01-06-2005

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

Anonymous · ‎01-06-2005

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 "Nathan Taylor" wrote in message news:[email protected]... > 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

Anonymous · ‎01-07-2005

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? -- http://www.caddzone.com AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 http://www.acadxtabs.com "Laurie Comerford" wrote in message news:41de3493_1@newsprd01... > 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 > > > > "Nathan Taylor" wrote in message > news:[email protected]... >> 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 > >

Anonymous · ‎01-07-2005

"Laurie Comerford" wrote in message news:41ddcdf6_2@newsprd01... > Hi Tony, > > They certainly do, but the data is not readily shareable. 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. -- http://www.caddzone.com AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 http://www.acadxtabs.com

Anonymous · ‎01-07-2005

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 "Tony Tanzillo" wrote in message news:41de4441$1_3@newsprd01... > 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? > > -- > http://www.caddzone.com > > AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 > http://www.acadxtabs.com > > "Laurie Comerford" wrote in message news:41de3493_1@newsprd01... > > 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 > > > > > > > > "Nathan Taylor" wrote in message > > news:[email protected]... > >> 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 > > > > > >

Anonymous · ‎01-07-2005

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: > GetSettings and SaveSettings save the data under the > Current User and as such are not helpful on computers > used by multiple users. 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). -- http://www.caddzone.com AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 http://www.acadxtabs.com "Laurie Comerford" wrote in message news:41de756f_3@newsprd01... > 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 > > > "Tony Tanzillo" wrote in message > news:41de4441$1_3@newsprd01... >> 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? >> >> -- >> http://www.caddzone.com >> >> AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005 >> http://www.acadxtabs.com >> >> "Laurie Comerford" wrote in message > news:41de3493_1@newsprd01... >> > 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 >> > >> > >> > >> > "Nathan Taylor" wrote in message >> > news:[email protected]... >> >> 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 >> > >> > >> >> > >

Anonymous · ‎01-07-2005

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 "Laurie Comerford" wrote in message news:41de756f_3@newsprd01... 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

Anonymous · ‎01-07-2005

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 "R. Robert Bell" wrote in message news:41dea684_1@newsprd01... > 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 > > > "Laurie Comerford" wrote in message > news:41de756f_3@newsprd01... > 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 > >

Anonymous · ‎01-08-2005

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 "Laurie Comerford" wrote in message news:41df350c_3@newsprd01... 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 "R. Robert Bell" wrote in message news:41dea684_1@newsprd01... > 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 > > > "Laurie Comerford" wrote in message > news:41de756f_3@newsprd01... > 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. >

Anonymous · ‎01-08-2005

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. -- Saludos, Ing. Jorge Jimenez, SICAD S.A., Costa Rica "R. Robert Bell" wrote in message news:41e004c8_1@newsprd01... >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 > > > "Laurie Comerford" wrote in message > news:41df350c_3@newsprd01... > 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 > > > "R. Robert Bell" wrote in message > news:41dea684_1@newsprd01... >> 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 >> >> >> "Laurie Comerford" wrote in message >> news:41de756f_3@newsprd01... >> 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. >> > >

Anonymous · ‎01-09-2005

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

Anonymous · ‎01-10-2005

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

Anonymous · ‎01-10-2005

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!

Anonymous · ‎01-10-2005

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 ---- "Oberer" wrote in message news:[email protected]... > 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!

Community

Saving & Restoring User Info on Forms

Saving & Restoring User Info on Forms

Saving & Restoring User Info on Forms