Saving form data
in [Visual Basic]
|
From: mp on 20 Jun 2010 14:40 "Larry Serflaten" <serflaten(a)gmail.com> wrote in message news:hvlijo$9n9$1(a)news.eternal-september.org... > > "mp" <nospam(a)Thanks.com> wrote > >> so FormSettings.ReadFile would just read a text file, parse the lines >> with >> split >> and fill Data(n) accordingly? >> that means i also have to cast strings to other datatypes if >> req'd(longs,doubles,etc) >> lots more code than one call to a get/put function :-) > > No extra typecasting code, Print and Line Input work with Variants. ah I see. I'm used to reading text files as strings sBuf = Input$(LOF(lngFnum), #lngFnum) so i always think of a text file as containing strings i'll look into Line Input > Your form sets the value, and Print sends it to the disk. Line Input > reads it back from the disk and sets the value, just like your form does. > Once you get the code working, you don't need to touch it again, > so what if it takes half a dozen more lines??? > quite true > >> so i guess i can combine any or all of the below methods as fits the >> situation. >> >> use a standardized udt in util.bas for common form properties >> use a generic SettingsClass to handle 'extended' form properties (if >> primarily strings) >> use an app specific udt for 'extended' form properties if lots of >> typecasting is requ'd > > It really depends on what you're after. If you want a bas module, > you'll be stuck having to adjust and tweak it for every app that > has a unique setting. (meaning, you'd have multiple copies of that > module code, one file for each unique app) If you want to write it > once and use it forever, (as is), then the class method is what you > want. > > Its your option... > LFS > Thanks to all who have contributed ideas This has been very edifying and enjoyable for me mark i thank the universe this group is still alive
From: GS on 20 Jun 2010 15:16 mp explained on 6/20/2010 : > "GS" <gesansom(a)netscape.net> wrote in message > news:hvk6qc$ei1$1(a)news.eternal-september.org... >> mp explained on 6/19/2010 : > snip >>> searching google now but if any one has the solution I"d appreciate it. >>> Thanks >>> Mark >> >> As Mayayana suggests, you should only ever have one instance of a UDT that >> is declared in a standard module with public scope so its members can be >> accessed from anywhere in your project. >> > > see my reply to him...different forms have different data to save - i don't > see how to create a universal udt that would apply to all forms in all > projects(the ones that want to save state that is) > >> For example, the following two functions are what I actually use in my >> projects. They're not that different than the code examples I gave you >> previously, but they handle all my UDTs. The OptionsData is managed by an >> options dialog. The other two udeDataType members are handled by various >> procs in standard or class modules, as appropriate. >> > > so you have one OptionsData udt that is common to all forms in all projects? > > my current project is a form with multiple listboxes displaying file names in > selected folders- user(me) adds however many listboxes for multiple folder > selections. > so what this form wants to save(beyond size and location) is a list of > foldernames. > no other form in my other projects has that need so it's app specific... > does that make sense? > > thanks to everyone who is helping me understand this > I really appreciate all your time and effort > mark If you read my post carefully, it suggests using multiple UDTs for different types of data used within a specific project. So in the example, and as Larry states, the 3 UDTs used here are specific to all projects in the context of general use. That means this is used as a template for all projects since it's highly likely I would want to manage those data types in any/every project. This is what I thought you were looking for. If I had need for another UDT for a specific project in addition to the basic ones shown in my example, it would be implemented and managed separately. There's no limit to the number of additional UDTs I could use in any one project, and each would be managed according to however I want as best suits the project. So, what you're saying is that you have use for UDTs that are project-specific only. What you implied was that you wanted a solution that was reusable in any project. Fact is, you can have it both ways and they all get handled in the same fashion. That is why, in my original post, I gave you 3 ways to construct file management methods; 1 to read only, 1 to write only, and 1 to read/write if you didn't want to use separate procs. This example suits servicing individual UDTs when they're project-specific. It seems that you're confusing our suggestions to use a single instance of your UDTs as not being able to use multiple UDTs. To clarify, you can use any number of UDTs but you should only create a single instance of each UDT. HTH -- Garry Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc
From: mp on 20 Jun 2010 15:19 "Larry Serflaten" <serflaten(a)gmail.com> wrote in message news:hvlijo$9n9$1(a)news.eternal-september.org... > > "mp" <nospam(a)Thanks.com> wrote > >> so FormSettings.ReadFile would just read a text file, parse the lines >> with >> split >> and fill Data(n) accordingly? >> that means i also have to cast strings to other datatypes if >> req'd(longs,doubles,etc) >> lots more code than one call to a get/put function :-) > > No extra typecasting code, Print and Line Input work with Variants. > Your form sets the value, and Print sends it to the disk. Line Input > reads it back from the disk and sets the value, just like your form does. from the help on Line Input Reads a single line from an open sequential file and assigns it to a string variable maybe that's also why i always thought of textfiles as containing strings is that line in the help incorrect?
From: GS on 20 Jun 2010 15:38 mp used his keyboard to write : > "Larry Serflaten" <serflaten(a)gmail.com> wrote in message > news:hvlijo$9n9$1(a)news.eternal-september.org... >> >> "mp" <nospam(a)Thanks.com> wrote >> >>> so FormSettings.ReadFile would just read a text file, parse the lines with >>> split >>> and fill Data(n) accordingly? >>> that means i also have to cast strings to other datatypes if >>> req'd(longs,doubles,etc) >>> lots more code than one call to a get/put function :-) >> >> No extra typecasting code, Print and Line Input work with Variants. >> Your form sets the value, and Print sends it to the disk. Line Input >> reads it back from the disk and sets the value, just like your form does. > > from the help on Line Input > Reads a single line from an open sequential file and assigns it to a string > variable > > maybe that's also why i always thought of textfiles as containing strings > > is that line in the help incorrect? The line is correct. A text file contains only text unless the content is binary. AFAIK, all text is String type. That means if you're storing numbers or boolean values, for example, then you'll have to convert them accordingly. -- Garry Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc
From: mp on 20 Jun 2010 19:19
"GS" <gesansom(a)netscape.net> wrote in message news:hvlqnp$64l$1(a)news.eternal-september.org... > mp used his keyboard to write : >> "Larry Serflaten" <serflaten(a)gmail.com> wrote in message >> news:hvlijo$9n9$1(a)news.eternal-september.org... >>> >>> "mp" <nospam(a)Thanks.com> wrote >>> >>>> so FormSettings.ReadFile would just read a text file, parse the lines >>>> with >>>> split >>>> and fill Data(n) accordingly? >>>> that means i also have to cast strings to other datatypes if >>>> req'd(longs,doubles,etc) >>>> lots more code than one call to a get/put function :-) >>> >>> No extra typecasting code, Print and Line Input work with Variants. >>> Your form sets the value, and Print sends it to the disk. Line Input >>> reads it back from the disk and sets the value, just like your form >>> does. >> >> from the help on Line Input >> Reads a single line from an open sequential file and assigns it to a >> string variable >> >> maybe that's also why i always thought of textfiles as containing strings >> >> is that line in the help incorrect? > > The line is correct. A text file contains only text unless the content is > binary. AFAIK, all text is String type. That means if you're storing > numbers or boolean values, for example, then you'll have to convert them > accordingly. > > -- > Garry > > Free usenet access at http://www.eternal-september.org > ClassicVB Users Regroup! comp.lang.basic.visual.misc > thats' what I had thought but Larry said I don't have to cast so I'm confused. mark |