j wrote:I do not think that this is a trivial task. You may want to make a proposal/feature request on the SumataraPDF Issue tracker, as SumatraPDF has the same selection mechanism. Also this would definitely be out of scope for my "fork" and material for the upstream project. Nevertheless, if I find some time maybe I can spend some thoughts on it... because I would prefer an "Adobe-like" selection mechanism too. Maybe look at Issue 778 too.
I see, thanks for the answer. Since I never used Sumatra PDF, I thought it's already implemented. Don't need to bother about it them.
j wrote:It uses the language of your operating system and defaults to English. So this behavior is intended (and also the same in the regular SumatraPDF). For reference see GetUserDefaultUILanguage as this is used to determine your OS language.
Any chance of saving the configuration in the plugin directory instead of Total Commander directory? (files lsplugin.ini and sumatrapdfprefs.dat)
I have the TC plugins in a shared directory, and I don't like having to redo the configurations every time I switch to another computer. (Also, the TC directory may not be accessible to a restricted user account).
Also, TC plugins may be used outside TC (as long as this other application supports the plugin interface), and I shouldn't have to redo the plugin configuration with every other application.
aNDreas Bolotă The truth always carries the ambiguity of the words used to express it. (Frank Herbert, God Emperor of Dune)
ND wrote:Any chance of saving the configuration in the plugin directory instead of Total Commander directory? (files lsplugin.ini and sumatrapdfprefs.dat)
Actually it is "best" practice as it is now. The ini file is given by ListDefaultParamStruct::DefaultIniName and that location is used.
This is usually your profile directory as long as you don't use a global ini-file.
The sumatrapdfprefs.dat shouldn't be saved at all - this is definitely a bug and will be fixed when I get home.
@j
i suggest not to use "force" in detectstr. I have exceptions when opening .exe in Plugins mode. Or- if you want "force"- you *must make autodetection of pdf by content.
Alextp wrote:@j
i suggest not to use "force" in detectstr. I have exceptions when opening .exe in Plugins mode. Or- if you want "force"- you *must make autodetection of pdf by content.
Ok, I guess I'll add an auto detection rule then.
Thanks for the information.
Not having the doc at hand atm, is "force" and "ext" mutually exclusive? Or when you have "force" then you need to provide a detect string and "ext" is just an additional check?
not mutualy exclusive.
If you have force, you must make autodetection not by extension. E.g.: you have "ext="exe"", and want to autodetect .drv files. For pdf: not needed.
Alextp wrote:not mutualy exclusive.
If you have force, you must make autodetection not by extension. E.g.: you have "ext="exe"", and want to autodetect .drv files. For pdf: not needed.
On the other hand PDFs have a quite simple signature ("%PDF-VERSION") and there might be files that don't have a PDFs extension that are still PDFs.
Anyway, I'll make fix for it in on or the other way.
Alextp wrote:- not all btns have hints.
- About btn can show text in Edits, selectable. And: system backgnd color, not yellow ..
- if tool is actually hand, why it is not "Hand" cursor? When Ctrl pressed, can be chged to "I"
Most of the issues come from the original SumatraPDF. Buttons miss a hint, when there is no translation available (or when I made a typo...ehm).
It would be better to check if the problem exists with the original SumatraPDF Reader and open issues on their bugtracker. Those bugs should be fixed there (which does not imply that I could not make a patch for them too).
Alextp wrote:To put to totalcmd.net, write to flint-inc.ru author.
I did a couple of days ago. No reply yet.
fenix_productions wrote:Looks like my issue is supposed to be fixed: