@John: That solves the problem, in fact. Many thanks. I'm a bit ashamed that I couldn't find such a simple solution. But I'm happy, because now I can get back on track.
*Rui Viana Pereira* John Aspinall <john.aspin...@gmail.com> escreveu no dia quarta, 6/12/2023 à(s) 16:13: > Hi Rui - on my system (Windows 10, Pharo 11 with Pharo-OS-Windows package) > both of the following work fine: > > WinShell shellOpen: 'd:\temp\test audio.mp3’. > > WinShell shellOpen: 'd:/temp/test audio.mp3’. > > Evaluating either one from a Playground opens the mp3 file with the > registered app (VLC in this case). > > WinExplorer explore: does nothing when passed a filename, but with just a > pathname (e.g. ‘d:/temp’) opens a Windows Explorer on that path > > Hope this helps? > > John > > > > On 6 Dec 2023, at 15:56, Rui Viana Pereira <ruivianapere...@gmail.com> > wrote: > > @Guillermo: Very useful remark, it made me review my code. First of all, I > refactored it to assure the address is written correctly, that is, with a > separator '\' instead of '/'. (I suppose there is a method to convert > paths from Pharo to DOS, but I couldn't find it, so I reinvented the wheel.) > Still, nothing happens. > > Then, I evaluated > WinExplorer explore: 'D:\Sonoteca_sample\CRIANCAS\criancas_001.wav' > putting the argument by hand. This is a file that exists and the argument > worked well when introduced directly on the Win explorer search bar, > without complaints from Windows. Still nothing happens, and the Inspector > tells a WinHandle(@ 16r0000001F). > > Is the #explore: method the right one to use? (I mean, to open the file > with the registered program in Windows). > > This is quite annoying, because apart from that the app is working well in > Pharo, even if it needs some cleaning. But after a lot of weeks of work > (I'm a beginner, I go very slowly in my spare time) I came to the > conclusion that it was useless work, because I can't communicate with > Windows shell, which is a very important part of my aims. > > [Side note: > What I'm building is a very simple app, ment to organize and classify my > field sound recordings. A kind of database for a sound library. It has only > 2 classes: SoundRecording and SoundLibrary. And a few presenters. > SoundLibrary holds <recordings> (aSet), <tags> (aSet) and <directory> > (aFileReference, which allows the library folder to be movable). A > SoundRecording holds a bunch of properties needed for professional > information and editing on sound files, plus an <address> (a relative > FileReference), which is the central piece for identifying each > recording/file. There is some automatic methods, including a scanner to > search for files in the library and automatically create SoundRecording > objects from each file found. This is crucial, because by now I have > thousands of recordings. > Next step would be to do the same with my books/docs library, which also > goes by thousands and is an awful amount of garbage - non organized, > classified and cross referenced information is nothing more than garbage] > > *Rui Viana Pereira* > > > Guillermo Polito <guillermopol...@gmail.com> escreveu no dia quarta, > 6/12/2023 à(s) 08:23: > >> Hi Rui, >> >> Just a quick look at the Win32 error codes >> >> >> https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- >> >> It tells me that 16r00000002 means “File not found”. >> Are you sure that c:\pharo.pdf is there and that you have permission to >> open it? >> >> G >> >> El 5 dic. 2023, a las 21:12, Rui Viana Pereira <ruivianapere...@gmail.com> >> escribió: >> >> I'm building an app with Pharo 11. >> The OS (for the moment) is Windows 10 home. >> At a certain point I need to open several types of files (pdf, wav, url, >> etc.) with the registered apps in Windows (or any other OS) and keep >> working in Pharo, in parallel. >> I couldn't find the way to do it - that is, to use the Windows shell. >> >> I loaded the Pharo-OS-Windows package, but when I evaluate something like >> WinShell shellOpen: 'c:\pharo.pdf' >> apparently nothing happens. >> The inspector gives me >> a WinHandle(@ 16r00000002) >> Which is the right way to do it? >> Rui Viana Pereira >> >> >> >
