Daniel Skorka wrote: > > Wow, you really seem to have spent quite some time on this; good work > too. I (and propably most of us here) do not really feel qualified to > answer your question about a workaround to this, were are mostly users > ot developers after all. However, right at the end of the bug comments > there's one saying that native shdocvw works. Is that an option for you? > > Daniel Thanks. I've been working hard at this because, if I want it fixed, I've got to do the majority of the work. I am just now at a point where I don't understand enough what is causing the crash to really fix it without making it worse, so I figured maybe other users might see something like this. It didn't seem appropriate for a developers forum until I at least tried to fix it myself. At any rate, it works to a point. It won't ever display the list of caches (there are 41 in a default database) or anything. Eventually it runs into a shell fixme that is labelled "semi-stub" which I think kills it. I have to check some real debug output to be sure as I was just doing a quick test this morning, but it doesn't really appear work. Louis Lenders suggested both native SHDOCVW.DLL and SHLWAPI.DLL, but when I add SHLWAPI.DLL, it crashes. I'm unsure why there. Maybe he's using a different version of wine. I was using a compiled version from about a day or so ago (although I've tried many others). At this point, my problem appears to be that I can not determine WHAT that functionality that was provided by the old dependence on the Mozilla ActiveX control really did for my application. Whatever it was, the messages that get sent to shdocvw.dll either don't get sent or are properly handled elsewhere and it worked... If I have to, I'll make a temporary patch for my use until I don't need it, but it seems kind of a hollow solution working against moving wine toward its goals. Plus I'd have to keep reapplying the stupid thing until I found I didn't need it anymore. Also, I don't know if there are any other apps that experience this (I suspect not since GSAK appears to be the first to come up against it), but it would be better if NO other apps experienced it. There is one thing I thought of that could be a problem with my using native DLLs and that is the source. I was wondering if there was a well known, safe source, for win2k, win98, and win95 dlls. I run win2k and can get DLLs from there, but I figure it might be a good idea to attempt to use the same DLLs as others using wine use (maybe everyone else is using native '98 DLLs for example). Anyway, I'm unsure if people are using win95 DLLs or win2k DLLs by default now when they use native DLLs. There doesn't seem to be a reference on that point. So I figure someone who's been using native DLLs might let me know. Thanks to those who have steered me to where I am at thus far. If I do get a viable workaround, be sure it will be posted prominently so others may benefit from the results as this seems to be a real bugger for GSAK. _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
