[Bug 44071] SPFLite Editor crashes on nullpointer

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Mar 3 17:32:55 CST 2018


https://bugs.winehq.org/show_bug.cgi?id=44071

--- Comment #9 from steve donato <stevedonato at gmail.com> ---
(In reply to steve donato from comment #6)
> (In reply to steve donato from comment #4)
> > As you recommended I went clicked on winehq developemnt 3.3 but it
> > downloaded 3.2?
> > Anyway, that version 3.2 worked fine and fixed the problem and installed
> > SPFLight, however alost all of my pre-installed apps such as Microsoft 2003 office msword did not work. It just got the spinning cursor doing something but then just back to  normal desktop and did nothing, never visibly launching anything. (Wine does not give weeor when directory not found' I did run a different old pre-installed program that did work fine (prism Plus
> > from NCH software).
> > 
> > So what was the problem, well I have to CLOSE original bug since 3.2 fixed the problem but Found another issue. If you don't re-install all your apps coming from a different Wine program (for example  HQ vs Staging). "wrong wine directory name in old apps properties fails". You have to either re-install almost all window apps or, drop down Linux menu and for wine apps menu entries and say add to desktop. Then right cick the desktop icon, select properties and edit the directory name for wine. In my case from wine-staging to to wine-hq. 
>    Unfortunately wine does NOT give you the error 'directory not found'
> which it should. Instead it just ends. I had to add the wine apps in the
> menu to the desktop because I do not how to get to the properties of an app
> entry in the Linux Menu list. (I am using Linux Mint 18 cinnamon)
> After the properties are edited to point to the proper wine directory the
> desktop symbolic link icon will invoke your win app properely because it
> finds the wine directory. But remember the entries in the Menu will still do
> NOT work so you cannot add them to panel because these entries still have
> the wrong path/directory associated with them for wine. If you have too many
> apps, another sleazy but may be necessary thing you could do is to rename
> the wine-hq directory to your old/other wine version name of, in my case was
> 'wine-staging'. Just thought maybe you can make a symbolic link out of the old directory pointing to the new one? Anyway Not cool but renaming it will work especially if you have many win apps and no longer have the original installation disks. So all is good for wine-hq development 3.2.
Update. I found out why an old app I had installed worked without having to
rename. I am making an assumption that the Winw install as a symbolic link
named 'wine' that points to the proper current wine directory, because my old
app had the wine directory in its property simple called 'wine. Below is the
property of my old app that worked with out point directly to the wine-hq
directory. maybe somebody can make this the case for the future so not
directories ever have to be changed. Note My old app just had "wine" following
the .wine directory as the wine directory. It must be a link? Below is my old
apps command line in it's property entry;
env WINEPREFIX="/home/steve/.wine" wine C:\\windows\\command\\start.exe /Unix
/home/steve/.wine/dosdevices/c:/users/Public/Start\ Menu/Programs/Prism\ Video\
File\ Converter.lnk

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list