|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Impact of file numbersform load event the app opens an INI file using OPEN, getting the file number from the freefile() function. The file number is kept in a public variable. Then, in another form (the login form) the INI file is opened again (under certain circumstances) using the file number in the public variable of the initial (start up) form. This app has been running for years now, so I can't say that this "setup" has been causing problems, but I would like to further research the impact of how it is and how the file numbers are used and how this could be a problem. Does anyone know of detailed technical documentation that delves into the use of the file numbers by Windows, apps and so on? Thanks! Saga VB allocates new numbers (handles) as they're requested. I believe they're
sequential, but can't say how/if "holes" are filled. It really doesn't matter. If you request a number using FreeFile(), it's available at that moment. Use it or lose it, kinda. It may continue to be used until you close the file that was opened with it. At that point, you *really* need to request another FreeFile() the next time you want to open that/any file. That all said, you know INI access is better handled by the API, right? I think I've finally settled on a drop-in solution I can live with. You might want to take a look at http://vb.mvps.org/samples/kpIni if you haven't likewise. Show quote > I am "enhancing" an already existing app and found that in the initial > form > load event the app opens an INI file using OPEN, getting the file > number from the freefile() function. The file number is kept in a > public variable. Then, > in another form (the login form) the INI file is opened again (under > certain > circumstances) using the file number in the public variable of the > initial > (start up) form. > > This app has been running for years now, so I can't say that this > "setup" > has been causing problems, but I would like to further research the > impact > of how it is and how the file numbers are used and how this could be a > problem. > > Does anyone know of detailed technical documentation that delves into > the use of the file numbers by Windows, apps and so on? > > Thanks! > Saga "Karl E. Peterson" <karlNO@SPAMmvps.org> wrote in message I agree. Although I have seen lots of documentation, including extreme news:eEQF8ExVFHA.2172@tk2msftngp13.phx.gbl... > VB allocates new numbers (handles) as they're requested. I believe > they're > sequential, but can't say how/if "holes" are filled. It really > doesn't matter. If > you request a number using FreeFile(), it's available at that moment. > Use it or lose > it, kinda. It may continue to be used until you close the file that > was opened with > it. At that point, you *really* need to request another FreeFile() > the next time you > want to open that/any file. > recommendations in this ng, I have not really seen any docs detailing on how file numbers are used and the consequences of not getting a freefile() number everytime that you open a file. > That all said, you know INI access is better handled by the API, I know this, unfortunately, the person that developed this app > right? I think I've > finally settled on a drop-in solution I can live with. You might want > to take a look > at http://vb.mvps.org/samples/kpIni if you haven't likewise. apperantly did not, so s/he used the open and a do loop to get each INI line, ignoring those starting with a semi colon. Thanks for the link, I use the APIs directly, but if this is a more pwerful solution I will definitely adopt it. Thanks for the reply :-) Saga Show quote > -- > Working Without a .NET? > http://classicvb.org/petition > > > Saga wrote: >> I am "enhancing" an already existing app and found that in the >> initial >> form >> load event the app opens an INI file using OPEN, getting the file >> number from the freefile() function. The file number is kept in a >> public variable. Then, >> in another form (the login form) the INI file is opened again (under >> certain >> circumstances) using the file number in the public variable of the >> initial >> (start up) form. >> >> This app has been running for years now, so I can't say that this >> "setup" >> has been causing problems, but I would like to further research the >> impact >> of how it is and how the file numbers are used and how this could be >> a >> problem. >> >> Does anyone know of detailed technical documentation that delves into >> the use of the file numbers by Windows, apps and so on? >> >> Thanks! >> Saga > > > Saga wrote:
> I agree. Although I have seen lots of documentation, including extreme The *only* real consequence would be the same as if you used #1 for every Open. At> recommendations > in this ng, I have not really seen any docs detailing on how file > numbers are used > and the consequences of not getting a freefile() number everytime that > you open a file. some point, it would be likely that you'd use a handle that's already in use, and throw an error. >> That all said, you know INI access is better handled by the API, Ouch.>> right? I think I've >> finally settled on a drop-in solution I can live with. You might >> want to take a look >> at http://vb.mvps.org/samples/kpIni if you haven't likewise. > > I know this, unfortunately, the person that developed this app > apperantly did not, so > s/he used the open and a do loop to get each INI line, ignoring those > starting with a semi colon. > Thanks for the link, I use the APIs directly, but if this is a more I find it nicely encapsulated, and pretty powerful. Enjoy!> pwerful solution I will definitely adopt it. Later... Karl
Show quote
"Saga" <antiSpam@somewhere.com> wrote in message Gonna try my best, but it'll probably be obvious that I ain't no good atnews:eoEAoQxVFHA.3076@TK2MSFTNGP12.phx.gbl... > > "Karl E. Peterson" <karlNO@SPAMmvps.org> wrote in message > news:eEQF8ExVFHA.2172@tk2msftngp13.phx.gbl... > > VB allocates new numbers (handles) as they're requested. I believe > > they're > > sequential, but can't say how/if "holes" are filled. It really > > doesn't matter. If > > you request a number using FreeFile(), it's available at that moment. > > Use it or lose > > it, kinda. It may continue to be used until you close the file that > > was opened with > > it. At that point, you *really* need to request another FreeFile() > > the next time you > > want to open that/any file. > > > I agree. Although I have seen lots of documentation, including extreme > recommendations > in this ng, I have not really seen any docs detailing on how file > numbers are used > and the consequences of not getting a freefile() number everytime that > you open > a file. teachin' an' 'splainin' <g> If you're wonderin' what I think you're wonderin' ;-) You could try this simple test. Launch two new VB projects, paste this in the first one... Private Sub Form_Load() Open "foo1" For Output As #1 End Sub Private Sub Form_Unload(Cancel As Integer) Close #1 End Sub ....and paste this in the second one... Private Sub Form_Load() Open "foo2" For Output As #1 End Sub Private Sub Form_Unload(Cancel As Integer) Close #1 End Sub Run one, and while its running, run the other (so they run simultaneously). Both are opening a different file using the same file number (#1) . Do you get an error when you launch the second one? VB language file numbers aren't "Winders wide", nor are they "VB wide" in regards to separate projects (they're only "project wide"). They're just a source code thing for us programmers to easily reference and associate file actions and not actual OS file handles. While you will get an error opening a file as #1 if the program doing so also has another file opened as #1, there's no error if your VB program is opening a file as #1 while another running VB program has a different file opened as #1. So if your project is only doing minimal file stuff, like if you are only dealing with one file in the program, its technically OK to use Open "whatever path and filename" For Input As #1. Using FreeFile is an encouraged practice, especially in more complex programs that can have a multitude of files opened at the same time (sometimes conditionally), because you can assign a descriptive variable name as the file number without worrying about keeping track of what actual file numbers are used (so you don't get errors trying to re-use a number that is already opened/in use). It's easier to keep track of (and read the source code) with something like fnMasterFile = FreeFile. And its also easier for other programmers that inherit the project. Using FreeFile just makes life easier for you, and for any other programmers that have to (simultaneously or later on) deal with the source code because you don't have to deal with what numerical file numbers are for what files and if the file number is already being used by another opened file in the program. Thanks BeastFish
Yup, I reck'n that is what I was wonderin' Hey you runnin' for president? I'm votin' for ya! Saga Show quote "BeastFish" <beastf***@for-president.com> wrote in message news:d606bt$48g$1@domitilla.aioe.org... > "Saga" <antiSpam@somewhere.com> wrote in message > news:eoEAoQxVFHA.3076@TK2MSFTNGP12.phx.gbl... >> >> "Karl E. Peterson" <karlNO@SPAMmvps.org> wrote in message >> news:eEQF8ExVFHA.2172@tk2msftngp13.phx.gbl... >> > VB allocates new numbers (handles) as they're requested. I believe >> > they're >> > sequential, but can't say how/if "holes" are filled. It really >> > doesn't matter. If >> > you request a number using FreeFile(), it's available at that >> > moment. >> > Use it or lose >> > it, kinda. It may continue to be used until you close the file >> > that >> > was opened with >> > it. At that point, you *really* need to request another FreeFile() >> > the next time you >> > want to open that/any file. >> > >> I agree. Although I have seen lots of documentation, including >> extreme >> recommendations >> in this ng, I have not really seen any docs detailing on how file >> numbers are used >> and the consequences of not getting a freefile() number everytime >> that >> you open >> a file. > > > Gonna try my best, but it'll probably be obvious that I ain't no good > at > teachin' an' 'splainin' <g> > > If you're wonderin' what I think you're wonderin' ;-) You could try > this > simple test. Launch two new VB projects, paste this in the first > one... > > Private Sub Form_Load() > Open "foo1" For Output As #1 > End Sub > Private Sub Form_Unload(Cancel As Integer) > Close #1 > End Sub > > ...and paste this in the second one... > > Private Sub Form_Load() > Open "foo2" For Output As #1 > End Sub > Private Sub Form_Unload(Cancel As Integer) > Close #1 > End Sub > > Run one, and while its running, run the other (so they run > simultaneously). > Both are opening a different file using the same file number (#1) . > Do you > get an error when you launch the second one? > > VB language file numbers aren't "Winders wide", nor are they "VB wide" > in > regards to separate projects (they're only "project wide"). They're > just a > source code thing for us programmers to easily reference and associate > file > actions and not actual OS file handles. While you will get an error > opening > a file as #1 if the program doing so also has another file opened as > #1, > there's no error if your VB program is opening a file as #1 while > another > running VB program has a different file opened as #1. > > So if your project is only doing minimal file stuff, like if you are > only > dealing with one file in the program, its technically OK to use Open > "whatever path and filename" For Input As #1. Using FreeFile is an > encouraged practice, especially in more complex programs that can have > a > multitude of files opened at the same time (sometimes conditionally), > because you can assign a descriptive variable name as the file number > without worrying about keeping track of what actual file numbers are > used > (so you don't get errors trying to re-use a number that is already > opened/in > use). It's easier to keep track of (and read the source code) with > something like fnMasterFile = FreeFile. And its also easier for other > programmers that inherit the project. Using FreeFile just makes life > easier > for you, and for any other programmers that have to (simultaneously or > later > on) deal with the source code because you don't have to deal with what > numerical file numbers are for what files and if the file number is > already > being used by another opened file in the program. > > > "Saga" <antiSpam@somewhere.com> wrote in message Not as such, but file handles used by Windows and file numbers used by VBnews:e%232c0%23wVFHA.2684@TK2MSFTNGP09.phx.gbl > Does anyone know of detailed technical documentation that delves into > the use of the file numbers by Windows, apps and so on? are not the same thing although they behave essentially the same way. Storing the value returned by FreeFile is pretty useless unless the file is kept open throughout the life of the application. If the file is closed then any other use of the FreeFile function is potentially going to return the same file number and that could be a conflict. Besides, for INI files the app should be using the API functions and not doing it's own I/O like that. -- Reply to the group so all can participate VB.Net: "Fool me once..."
Show quote
"Bob Butler" <tiredofit@nospam.com> wrote in message Wouldn't the conflict present itself if the file was not closed?news:%23XCf2GxVFHA.3864@TK2MSFTNGP10.phx.gbl... > "Saga" <antiSpam@somewhere.com> wrote in message > news:e%232c0%23wVFHA.2684@TK2MSFTNGP09.phx.gbl >> Does anyone know of detailed technical documentation that delves into >> the use of the file numbers by Windows, apps and so on? > > Not as such, but file handles used by Windows and file numbers used by > VB > are not the same thing although they behave essentially the same way. > > Storing the value returned by FreeFile is pretty useless unless the > file is > kept open throughout the life of the application. If the file is > closed > then any other use of the FreeFile function is potentially going to > return > the same file number and that could be a conflict. > The app closes the file after it is done with it, so that is why the conflict issue hasn't come up when the file is reopened, even if it uses the same file number. Even so I saw that as a big "don't". > Besides, for INI files the app should be using the API functions and Sigh, see the reply I gave Karl.> not > doing it's own I/O like that. > Thanks for the reply Saga Show quote > -- > Reply to the group so all can participate > VB.Net: "Fool me once..." >  |
|||||||||||||||||||||||
Other interesting topics