Kuba Ober wrote:
I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type
edit \\server\myhome\file.txt
And it opens it just fine.
Similarly, I can type
dir "\\server\shared files"
I'm sure the DOS utilities just use long file name APIs and those "simply
work". It should be the
> >>What's wrong with additional APIs? The browse folder API isn't COM based
> >>anyway.
> >
> >It would be much better to use the API provided to create a namespace for
> > the Unix filesystem. The Control Panel and Network Neighborhood are good
> > examples of this. Quite a few third party apps c
>
> Hmm. For the winecfg use case though we have to pass back a Unix path,
> as by definition it might not be mapped to a Windows path. I suspect
> most code that uses the browse folder API converts the PIDL straight
> into a path that it can use with CreateFileEx and so on so it might
> break stu
On Mon, 2004-12-06 at 17:07 +0100, Alexandre Julliard wrote:
> Native file pickers are a completely different issue. What I'm talking
> about is the standard shell browser thing, except showing Unix paths
> instead of Windows drives, so that it's as transparent as possible to
> the app. If the app
Mike Hearn <[EMAIL PROTECTED]> writes:
> I don't see how to make this work. Silently replacing the win32 file
> pickers with native file pickers (or custom built-for-Unix Wine
> pickers) is possible in a few cases but when the app modifies the
> dialog with additional controls, we have to use the
Robert van Herk <[EMAIL PROTECTED]> writes:
> Do you want me to continue on my patch, or are you saying that you
> feel that this is not the way to go, so that I would be wasting time
> with further polishing it anyway?
I'm afraid so yes. We really don't want to define new APIs for that,
it needs
Alexandre Julliard wrote:
I'm afraid so yes. We really don't want to define new APIs for that,
it needs to be integrated properly with the existing code. Ideally a
Winelib app should be able to start using Unix dialogs without code
changes at all.
I don't see how to make this work. Silently replaci
Mike Hearn wrote:
Alexandre Julliard wrote:
Well, there's an IShellFolder interface, and it should probably be
doing something with that. In any case it should definitely be more
integrated into the shell way of doing things, there shouldn't be a
need for a whole new set of APIs. This needs more th
Alexandre Julliard wrote:
Well, there's an IShellFolder interface, and it should probably be
doing something with that. In any case it should definitely be more
integrated into the shell way of doing things, there shouldn't be a
need for a whole new set of APIs. This needs more thought IMO...
I hav
Steven Edwards wrote:
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
What's wrong with additional APIs? The browse folder API isn't COM based
anyway.
It would be much better to use the API provided to create a namespace for
the Unix filesystem. The
Control Panel and Network Neighborhood are goo
Hi,
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Well, there's an IShellFolder interface, and it should probably be
> doing something with that. In any case it should definitely be more
> integrated into the shell way of doing things, there shouldn't be a
> need for a whole new set of APIs.
Mike Hearn <[EMAIL PROTECTED]> writes:
> On Thu, 02 Dec 2004 15:19:27 +0900, Mike McCormack wrote:
> > How about creating a new object class or interface to an existing object
> > that exposes these interfaces? That way you won't need to export any
> > extra functions from shell32.
>
> What's
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> What's wrong with additional APIs? The browse folder API isn't COM based
> anyway.
It would be much better to use the API provided to create a namespace for the
Unix filesystem. The
Control Panel and Network Neighborhood are good examples of this. Quit
On Thu, 02 Dec 2004 15:19:27 +0900, Mike McCormack wrote:
> How about creating a new object class or interface to an existing object
> that exposes these interfaces? That way you won't need to export any
> extra functions from shell32.
What's wrong with additional APIs? The browse folder API i
Robert van Herk wrote:
Added functionality to browse for a UNIX folder.
This is done by making two new funtions in dlls/shell32/brsfolder.c, namely
wine_shell_browse_for_UNIX_directoryA
wine_shell_browse_for_UNIX_directoryW
These functions are exported in shlobj.h.
How about creatin
Robert van Herk wrote:
So yes, I could put it all in a structure on the stack and then pass
it to the dlgproc, but it will only arrive there on WM_INITDIALOG.
However, I will also need the structure when the other messages come
in. So where do I save it then, if I cannot put it in a global var?
However I can definitely see your point here but since the functions are
all internal to shell32 at this point and can accept any parameters you
may like, I would consider it a cleaner solution to allocate a structure
on the stack which contains such helper variables together with the pointer
to
Rolf Kalbermatter wrote:
Robert van Herk wrote:
I guess you are right, but the strange thing is that this was already
the case in the original code. The hwnd of the tree view and the
pointer to the browseinfo structure are copied into a global variable,
so at least my code is not worse here :-)
Robert van Herk wrote:
> I guess you are right, but the strange thing is that this was already
> the case in the original code. The hwnd of the tree view and the
> pointer to the browseinfo structure are copied into a global variable,
> so at least my code is not worse here :-).
Well, existing c
Rolf Kalbermatter wrote:
Robert van Herk wrote:
-LPITEMIDLIST WINAPI SHBrowseForFolderA (LPBROWSEINFOA lpbi)
+static INT_PTR BrowseW (LPBROWSEINFOW lpbi, DLGPROC dlgproc, enum browsemode aBrowseMode)
+{
+INT_PTR ret;
+
+browseMode = aBrowseMode;
^^
Robert van Herk wrote:
>-LPITEMIDLIST WINAPI SHBrowseForFolderA (LPBROWSEINFOA lpbi)
>+static INT_PTR BrowseW (LPBROWSEINFOW lpbi, DLGPROC dlgproc, enum browsemode
>aBrowseMode)
>+{
>+INT_PTR ret;
>+
>+browseMode = aBrowseMode;
^^
I may miss something he
Hi,
I had some problems with my mail server, so I send in this patch again.
If the previous one did arrive, please ignore this e-mail.
Changes:
Added functionality to browse for a UNIX folder.
This is done by making two new
Changes:
Added functionality to browse for a UNIX folder.
This is done by making two new funtions in dlls/shell32/brsfolder.c, namely
wine_shell_browse_for_UNIX_directoryA
wine_shell_browse_for_UNIX_directoryW
These functions are exported in shlobj.h.
The original code that allowed ju
23 matches
Mail list logo
