For some reason my application seems to remember the current directory
where the image was saved, and does not return the directory where it gets started up as a packaged runtime. Any ideas? Is Filename currentDirectory not the right way to get this information? Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
"ObjectMemory imageName asFilename head" is a better way for that. " Filename getDefaultDirectory asByteString" gives the OS default directory ; you can set it in a shell script (Linux) or in the Windows shortcut. MT Le mardi 10 juillet 2012 à 22:03 -0400, Carl Gundel a écrit : > For some reason my application seems to remember the current directory > where the image was saved, and does not return the directory where it > gets started up as a packaged runtime. Any ideas? > > Is Filename currentDirectory not the right way to get this information? > > Thanks, > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Carl Gundel-2
On 7/11/2012 4:03 AM, Carl Gundel wrote:
> For some reason my application seems to remember the current directory > where the image was saved, and does not return the directory where it > gets started up as a packaged runtime. Any ideas? > > Is Filename currentDirectory not the right way to get this information? try Filename defaultDirectory If this shows an old directory you'll need to check whether Filaneme class>>install runs at image start and/or whether some of your code changes the value of the shared Filename.DefaultDirectoryString See Filename class>>findDefaultDirectory for the dynamic variant. R - _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Martial Tarizzo
I don't know Carl's installation layout, but for most packaged software these days, the image will not be in the working directory. E.g. on Windows the image will be read-only under Program Files and the working directory under My Documents.
Filename currentDirectory can become out of sync with the OS's view of what is the actual working directory, e.g. while using a native file dialog (depends on the settings used while calling it). Windows docs say not to rely on the OS working directory. Sadly, VW relative filenames use it, rather than using Filename currentDirectory. You can see the difference between currentDirectory (normally relative), defaultDirectory (fixed at startup), and OS directory (which relative filenames use) by running the attached workspace script and changing directory in the file dialog that opens. One other gotcha: If you double-click an image (with a standard association to VisualWorks.exe), it will start up with the current directory being that of the image file. The exception is if you use a Windows Explorer search to find the image file - then it starts up in %WINDIR%\system32. Steve Martial [[hidden email]] wrote: > "ObjectMemory imageName asFilename head" is a better way for that. > > " Filename getDefaultDirectory asByteString" gives the OS default > directory ; you can set it in a shell script (Linux) or in the Windows > shortcut. > > MT > > > Le mardi 10 juillet 2012 à 22:03 -0400, Carl Gundel a écrit : > > For some reason my application seems to remember the current > directory > > where the image was saved, and does not return the directory where it > > gets started up as a packaged runtime. Any ideas? > > > > Is Filename currentDirectory not the right way to get this > information? > > > > Thanks, > > > > -Carl Gundel > > http://www.libertybasic.com > > http://www.runbasic.com > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc workingDir.txt (1K) Download Attachment |
In reply to this post by Carl Gundel-2
Hi Carl,
In my development image, #currentDirectory answers '.', which may not be terribly helpful. Using native dialogs (file open/save) in the VW image can change #currentDirectory for the remainder of your VW session (at least with VW 7.6 on Win XP).
If you freshly start an image, you won't really know the directory "where the image was saved" (especially if it was saved in dir1, then copied to dir2, or dir1 was renamed dir2, etc), but you can know the directory where the image was started from the command line using:
ObjectMemory imageDirectory
Also, if you saveAs an image to a different directory without quitting, #imageDirectory now points to the new location, even though #defaultDirectory and #currentDirectory still point to the old.
I don't know how this would behave for an image packaged in a Windoze .exe file.
When I used to do tech support for VisualWorks, I recall experimenting with different ways to launch an image on Windoze:
1) drag visual.im onto vwnt.exe
2) double-click visual.im when a VM is the registered program for '.im' files
3) double-click visual.im when VisualWorks.exe is the registered program for '.im' files
4) use a Windoze shortcut that specifies a startup directory
5) use a Windoze shortcut that does not specify a startup directory
6) double-click visual.exe when a visual.im is found in the same directory
7) drag visual.im onto a shortcut to the VM
(etc)
On the whole, I found no rhyme nor reason to Windows' behavior regarding startup directory, and the only reliable behaviors I can recall are 3 and 4.
If your packaged runtime is an installer, then I recommend creating a shortcut with a specified startup directory. If you don't have an installer, the packaged app can try:
ObjectMemory imageDirectory
If that doesn't work for images that are packaged with the VM on Windows, then use:
CEnvironment commandLine
to parse the location yourself.
If your packaged runtime has no installer, it can 'install' a shortcut on first use; the parcel:
Windows Shortcuts
can produce a shortcut that specifies your startup directory. The VWInstaller uses this to produce shortcuts in the windows start menu (at least it did as of VW 7.6, I haven't paid much attention to the installer since then). This will allow user access in the Windows start menu regardless of where the executable is installed. Of course, if you also want your executable accessible from the command prompt (which I think is your case), then a shortcut may be of less use, and you want to go with #imageDirectory or #commandLine. Dave Stevenson[hidden email] From: Carl Gundel <[hidden email]> To: VWNC List <[hidden email]> Sent: Tue, July 10, 2012 9:03:43 PM Subject: [vwnc] [7.8] Filename currentDirectory For some reason my application seems to remember the current directory where the image was saved, and does not return the directory where it gets started up as a packaged runtime. Any ideas? Is Filename currentDirectory not the right way to get this information? Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Oh yes, once you find the directory you want, if that is not #currentDirectory, you can make it so by sending it #beCurrentDirectory. It will remain so unless you open any native file dialogs in which the user browses to a different directory, since Windoze makes that the new #currentDirectory.
The idea is to open the next file dialog in the same folder, which is useful for users but a pain for the application that relies on #currentDirectory not changing without its knowledge.
To get the best of both worlds, make a shared variable to hold the last 'browsed' directory. Then either in your application code just before opening a native file dialog, or in the native file dialog code itself, do something like:
| appDir |
appDir := Filename currentDirectory.
(LastBrowsedDirectory ifNil: [LastBrowsedDirectory := Filename currentDirectory])
beCurrentDirectory.
[<open native fileDialog>] ensure:
[LastBrowsedDirectory := Filename currentDirectory.
appDir beCurrentDirectory] Dave Stevenson[hidden email] From: Dave Stevenson <[hidden email]> To: [hidden email]; VWNC List <[hidden email]> Sent: Wed, July 11, 2012 9:39:04 AM Subject: Re: [vwnc] [7.8] Filename currentDirectory Hi Carl,
In my development image, #currentDirectory answers '.', which may not be terribly helpful. Using native dialogs (file open/save) in the VW image can change #currentDirectory for the remainder of your VW session (at least with VW 7.6 on Win XP).
If you freshly start an image, you won't really know the directory "where the image was saved" (especially if it was saved in dir1, then copied to dir2, or dir1 was renamed dir2, etc), but you can know the directory where the image was started from the command line using:
ObjectMemory imageDirectory
Also, if you saveAs an image to a different directory without quitting, #imageDirectory now points to the new location, even though #defaultDirectory and #currentDirectory still point to the old.
I don't know how this would behave for an image packaged in a Windoze .exe file.
When I used to do tech support for VisualWorks, I recall experimenting with different ways to launch an image on Windoze:
1) drag visual.im onto vwnt.exe
2) double-click visual.im when a VM is the registered program for '.im' files
3) double-click visual.im when VisualWorks.exe is the registered program for '.im' files
4) use a Windoze shortcut that specifies a startup directory
5) use a Windoze shortcut that does not specify a startup directory
6) double-click visual.exe when a visual.im is found in the same directory
7) drag visual.im onto a shortcut to the VM
(etc)
On the whole, I found no rhyme nor reason to Windows' behavior regarding startup directory, and the only reliable behaviors I can recall are 3 and 4.
If your packaged runtime is an installer, then I recommend creating a shortcut with a specified startup directory. If you don't have an installer, the packaged app can try:
ObjectMemory imageDirectory
If that doesn't work for images that are packaged with the VM on Windows, then use:
CEnvironment commandLine
to parse the location yourself.
If your packaged runtime has no installer, it can 'install' a shortcut on first use; the parcel:
Windows Shortcuts
can produce a shortcut that specifies your startup directory. The VWInstaller uses this to produce shortcuts in the windows start menu (at least it did as of VW 7.6, I haven't paid much attention to the installer since then). This will allow user access in the Windows start menu regardless of where the executable is installed. Of course, if you also want your executable accessible from the command prompt (which I think is your case), then a shortcut may be of less use, and you want to go with #imageDirectory or #commandLine. Dave Stevenson[hidden email] From: Carl Gundel <[hidden email]> To: VWNC List <[hidden email]> Sent: Tue, July 10, 2012 9:03:43 PM Subject: [vwnc] [7.8] Filename currentDirectory For some reason my application seems to remember the current directory where the image was saved, and does not return the directory where it gets started up as a packaged runtime. Any ideas? Is Filename currentDirectory not the right way to get this information? Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Dave Stevenson-3
Dave wrote: >In my development image, #currentDirectory answers '.', which may not be terribly helpful. >Using native dialogs (file open/save) in the VW image can change #currentDirectory for the >remainder of your VW session (at least with VW 7.6 on Win XP). This forced me to add a StartupDirectory shared variable and use absolute path names. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== From: [hidden email] [mailto:[hidden email]] On Behalf Of Dave Stevenson Hi Carl, In my development image, #currentDirectory answers '.', which may not be terribly helpful. Using native dialogs (file open/save) in the VW image can change #currentDirectory for the remainder of your VW session (at least with VW 7.6 on Win XP). If you freshly start an image, you won't really know the directory "where the image was saved" (especially if it was saved in dir1, then copied to dir2, or dir1 was renamed dir2, etc), but you can know the directory where the image was started from the command line using: ObjectMemory imageDirectory Also, if you saveAs an image to a different directory without quitting, #imageDirectory now points to the new location, even though #defaultDirectory and #currentDirectory still point to the old. I don't know how this would behave for an image packaged in a Windoze .exe file. When I used to do tech support for VisualWorks, I recall experimenting with different ways to launch an image on Windoze: 1) drag visual.im onto vwnt.exe 2) double-click visual.im when a VM is the registered program for '.im' files 3) double-click visual.im when VisualWorks.exe is the registered program for '.im' files 4) use a Windoze shortcut that specifies a startup directory 5) use a Windoze shortcut that does not specify a startup directory 6) double-click visual.exe when a visual.im is found in the same directory 7) drag visual.im onto a shortcut to the VM (etc) On the whole, I found no rhyme nor reason to Windows' behavior regarding startup directory, and the only reliable behaviors I can recall are 3 and 4. If your packaged runtime is an installer, then I recommend creating a shortcut with a specified startup directory. If you don't have an installer, the packaged app can try: ObjectMemory imageDirectory If that doesn't work for images that are packaged with the VM on Windows, then use: CEnvironment commandLine to parse the location yourself. If your packaged runtime has no installer, it can 'install' a shortcut on first use; the parcel: Windows Shortcuts can produce a shortcut that specifies your startup directory. The VWInstaller uses this to produce shortcuts in the windows start menu (at least it did as of VW 7.6, I haven't paid much attention to the installer since then). This will allow user access in the Windows start menu regardless of where the executable is installed. Of course, if you also want your executable accessible from the command prompt (which I think is your case), then a shortcut may be of less use, and you want to go with #imageDirectory or #commandLine. Dave Stevenson From: Carl Gundel <[hidden email]> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |