Problem with common control... 2

[JFRobishow]

Hi everyone,

I'm working on a small application at the same time as I teach myself VB 6. I'm trying right now to fix a new error that occured today and while I think I identified the source of the error I can't fix it.

I'm populating a combobox using a text file with this procedure -->

Private Sub FillComboBox()
Dim currentLine As String
Dim intFreeFile As Integer

intFreeFile = FreeFile

On Error GoTo ErrorFillComboBox

    Open "ressources\fileInput.txt" For Input As intFreeFile
    Do Until EOF(intFreeFile)
        Line Input #intFreeFile, currentLine
        sortedList.AddItem currentLine
    Loop
    
    'Close the file
    Close #intFreeFile
    
    'Add each item of the list in the combo box.
    For i = 0 To sortedList.ListCount
        comboFromFile.AddItem sortedList.List(i)
    Next
    Exit Sub
    
ErrorFillComboBox:
    MsgBox Err & ":Error in FillComboBox.  Error Message: " & Err.Description, vbCritical, "Warning"
    Exit Sub

End Sub

It correctly find the file named "fileInput.txt" in the folder "ressources" which is in the project directory.

That always worked until today...

I tried adding a common control to the form so that the user could browse to a file, select it and the path would be added in a text area...here's my code :

Private Sub buttonBrowse1_Click()
    FileOpenDlg.ShowOpen  
    textPath1.Text = FileOpenDlg.FileName

End Sub

The problem I have is after I select a file using the Common Control and close the form and open it again (it's the 2nd form the first one just open the 2nd form), I get a "Path not Found" in FillComboBox...I assume it can't find the path : ressources\fileInput.txt

If I close the whole application and re-open it it work again until I use the Common Control again.

I've been testing playing with it for a while and so far I'm thinking that when I use the Common Control and select a file it change the working directory to where the selected file is. I've tested this by copying the folder "ressources" to my E:\ drive, I then used the Common Control to select a file that was directly on E:
Sure enough it continued working since E:\ressources\fileInput.txt existed

If I remove the folder "ressources" and try again it's not working I get a "Path not Found" again.

I've tried in various location on the hard drive, continued getting error and finally I selected the project directory again and it started working...so from my test, it's changing the working directory.

Wheew, well that was a long post...I just wanted to show that I actually tried fixing the problem before running for help

Well now I think I've found the cause of the problem...as for the solution well I have no idea.

Is it possible to keep use a common control to select a file while still using virtual path to files the application use or will I have to use a full physical path to fileInput.txt?

 

[ponerse]

Here's the part I don't get:

"The problem I have is after I select a file using the Common Control and close the form and open it again (it's the 2nd form the first one just open the 2nd form), I get a "Path not Found" in FillComboBox...I assume it can't find the path : ressources\fileInput.txt"

It would be a good idea to have a module-level variable to hold the file location with all of this opening and closing of forms. Call it strFileLocation or something:

FileOpenDlg.ShowOpen
strFileLocation = FileOpenDlg.FileName
textpath1.text = strFileLocation

then:

Open strFileLocation For Input As intFreeFile
Do Until EOF(intFreeFile)
Line Input #intFreeFile, currentLine
sortedList.AddItem currentLine
Loop

etc, etc.


Be an idiot:

http://www.freakingidiot.com

 

[JFRobishow]

Hi ponerse,

Thanks for the reply, I know that parts of my post weren't clear, sorry about that, english is my second language.

The file I'm opening is just a text file that contain a list of choices and is located in a sub directory of my project.

I'm not using the FileOpenDlg to select the location of this file...I'm only trying to get the common control to update a Text area, which is working quite well.

However at the same time it's changing other things...I'll try to explain using a more detailed explanation of where my project is on my HD.

I have my project in E:\VB\CodeSamples
In there reside Project1.vbp and everything else.

That particular project have 2 forms, the first one only have buttons opening other forms.

The one I have the common control on, have a few combo boxes, a text area, a button (to browse) and a common control along with an OK/Cancel button that are not yet functional.

One of the combo box on that form is populated using a file that is in a sub directory of the project (E:\VB\CodeSamples\ressources\) that's where this come from.

Open "ressources\fileInput.txt" For Input As intFreeFile

That (anyway it's what my intention is) open fileInput.txt which is in directory "ressources" which is in it's turn in the project directory where the executable is.

Now as for the common control part...I was looking for an easy way to let an user browse to a file and then display the selected file path in a text area (instead of having to type the whole path themself)

I added a button which open the common control and then update the text area when the user click ok. That is working as the text area get updated with the correct path.

Say the user select the file "whatever.gif" from C:\ the text area will show C:\whatever.gif after the common control is closed.

The problem I have is when I then close that form which return me to the first one with the buttons opening other forms using formName.Show on button_Click() I get an error from my error handler that I have in the procedure filling the combobox saying "path not found" for the file I'm trying to open as input...that is "ressources\fileInput.txt"

That file is as I said located in my project directory, but it's not looking for it there it's looking for it in whatever path got selected with the common control when the form was previously open.

To resume quickly,

I have form1 with a button opening form2.

I click the button that open form2 using form2.Show

On form2 the combo box get populated correctly from the file (which is in a subdir of my project or E:\VB\CodeSamples\ressources\fileInput.txt).

I select a file using the browse button (common control)...let's say I select C:\whatever.gif

The text area is updated reflecting the selected path.
I close form2
I reopen form2 using the same button on form1
I get the error saying the "path not found" since it's now trying to open C:\ressources\fileInput.txt

It's happening wether I declare a string containing the path in the Form_Load() or use the path directly between quote ("ressources/file.ext") when I come to open the file I need.

It's not happening if I specify the full path "E:\VB\CodeSamples\ressources\fileInput.txt" of course.

I can specify the full path I guess, but I was thinking that if I ever build this application with the Package & Deployment Wizard and install say in C:\Program Files\ it would still look in E:\VB\CodeSamples\ressources\fileInput.txt since it's hard coded while just having a reference to a subdirectory (or virtual path) of where the .exe is would allow me have a dir containing all sort of .ini kind of files that my program would use and would know where to find them.

I was thinking along the way you code website using virtual path instead of full path containing the domain in case you ever change domain (e.g. <img src="images/logo.gif"> instead of <img src="http:\\mydomain.com/images/logo.gif">

Maybe I am just not doing this the right way as it seems the common control used to open file change the way the application handle the rest of the File Open if full paths aren't specified. I guess I could use a custom form with DriveListBox and all.

 

[ponerse]

I see, the "ressources\fileInput.txt" part is getting messed up. While telling you that using file names like this isn't good coding in the long run, I'll also tell you how to remain with the same path.

Try something like this:

strPath = App.path & "\ressources\fileInput.txt"

open strPath for input as .....

App.path is read-only as long as the program is running and won't change when the user changes around the working directory.



Be an idiot:

http://www.freakingidiot.com

 

[JFRobishow]

Thanks ponerse that did it!

I knew it wasn't a good idea when I was writing pseudo to literally tell my application where the file was but the problem is when I started coding it I didn't know how not to...so I thought I would at least keep every config files in one directory so that it doesn't get all messy in the main directory if I would ever have to use more than one config file.

How else could I store my application config files? Beside telling it where to look for them?

I'm thinking of a module variable or a Constant that would hold the path to the directory containing the files then each file could be referenced more directly like

strConfigDir & "\file1.ini"

Would that be a better way to do it? But then again if I don't want a hard coded path I would still have to use App.Path for the begining of the path name....

 

[ponerse]

When you say config files, what's in them? I think using app.path & "\settings\file.txt is fine for the most part, but you have may have to write some code that reproduces those file(s) if they are some how deleted.

For configuration settings (user and otherwise), I usually use the registry for such things. That way, everytime the application loads up, it's assured of at least having the default values loaded in. Check out the getsetting() and savesetting() functions for simplified registry access.

Be an idiot:

http://www.freakingidiot.com

 

[JFRobishow]

Hi ponerse,

By config file, I mean mostly files that contain values to initialise the app. Like combo box choices, etc...if a new one is entered by typing it's then added to the file so that it's in the combo box choices the next time...stuff like that (columns width, etc)

If they are deleted it wouldn't cause the app to stop functionning it just would reset back to default state which should be functional. They will then be re-created as user reset the settings.

I'll make sure to have a look at getsetting() and savesetting() also. I'm experimenting with VB learning at the same time it's a lot of fun guess I'll make a registry backup before messing with it though

Thanks a bunch for the help, I really appreciate it! Hopefully one day I'll be able to contribute to these forums with answering a few posts myself

 

[ponerse]

No problem, happy to help. The get and savesetting() really don't intefere with the registry that much, so don't be afraid to use them. Still, it's always a great idea to back it up anyway. Have fun with VB!

Be an idiot:

http://www.freakingidiot.com