Re: comdlg32: Resize Find dialog to fit translations
2012.12.02 20:32, Dmitry Timoshkov rašė:
> Aurimas Fišeras wrote:
>
>>>> Controls resized to fit translations for more languages. Tested with
>>>> resource editor.
>>>
>>> Did you see a comment in that file just before dialog templates?
>>>
>> Hello,
>> I obviously didn't notice that comment.
>>
>> Why do we have such a limitation?
>
> Applications that use custom dialog templates and subclass the original
> ones (or rather the algorithm in comctl32 that resizes custom dialogs)
> depend on this .
>
>> I checked the sizes of this dialog before conversion to po files [1] and
>> they were quite different between various languages.
>
> If the dialog sizes differ from Windows templates - that's a bug and
> should be fixed.
>
I see.
What about something like the attached patch? I resized both check boxes
and the direction group, positioned radio buttons in the direction group
one above the other.
I checked this dialog on Windows XP Lithuanian UI, and it had similar
differences from the English one.
From 7151dc5ce8a3bfa00010f47c6993ad3be7fd5a2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Aurimas=20Fi=C5=A1eras?=
Date: Sun, 2 Dec 2012 21:31:15 +0200
Subject: comdlg32: Move and resize controls of the Find dialog to better fit
translations
---
dlls/comdlg32/comdlg32.rc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc
index 7040fcc..7658e81 100644
--- a/dlls/comdlg32/comdlg32.rc
+++ b/dlls/comdlg32/comdlg32.rc
@@ -312,11 +312,11 @@ FONT 8, "MS Shell Dlg"
{
LTEXT "Fi&nd What:", -1, 4, 8, 52, 8
EDITTEXT edt1, 57, 7, 148, 12, ES_AUTOHSCROLL | WS_BORDER | WS_GROUP |
WS_TABSTOP
- CHECKBOX "Match &Whole Word Only", chx1, 4, 26, 120, 12, BS_AUTOCHECKBOX |
WS_GROUP | WS_TABSTOP
- CHECKBOX "Match &Case", chx2, 4, 42, 120, 12, BS_AUTOCHECKBOX | WS_TABSTOP
- GROUPBOX "Direction", grp1, 127, 26, 78, 28
- CONTROL "&Up", rad1, "BUTTON", BS_AUTORADIOBUTTON | WS_CHILD | WS_VISIBLE |
WS_GROUP | WS_TABSTOP, 131, 38, 35, 12
- CONTROL "&Down", rad2, "BUTTON", BS_AUTORADIOBUTTON | WS_CHILD | WS_VISIBLE |
WS_TABSTOP, 163, 38, 35, 12
+ CHECKBOX "Match &Whole Word Only", chx1, 4, 26, 140, 12, BS_AUTOCHECKBOX |
WS_GROUP | WS_TABSTOP
+ CHECKBOX "Match &Case", chx2, 4, 42, 140, 12, BS_AUTOCHECKBOX | WS_TABSTOP
+ GROUPBOX "Direction", grp1, 147, 21, 58, 38
+ CONTROL "&Up", rad1, "BUTTON", BS_AUTORADIOBUTTON | WS_CHILD | WS_VISIBLE |
WS_GROUP | WS_TABSTOP, 151, 30, 48, 12
+ CONTROL "&Down", rad2, "BUTTON", BS_AUTORADIOBUTTON | WS_CHILD | WS_VISIBLE |
WS_TABSTOP, 151, 44, 48, 12
DEFPUSHBUTTON "&Find Next", IDOK, 212, 6, 60, 14, WS_GROUP | WS_TABSTOP |
BS_DEFPUSHBUTTON
PUSHBUTTON "Cancel", IDCANCEL , 212, 24, 60, 14, WS_GROUP | WS_TABSTOP
--
1.8.0
Re: comdlg32: Resize Find dialog to fit translations
2012.12.02 07:46, Dmitry Timoshkov rašė: > Aurimas Fišeras wrote: > >> Controls resized to fit translations for more languages. Tested with >> resource editor. > > Did you see a comment in that file just before dialog templates? > Hello, I obviously didn't notice that comment. Why do we have such a limitation? I checked the sizes of this dialog before conversion to po files [1] and they were quite different between various languages. [1] http://source.winehq.org/git/wine.git/commit/1fa1ab54376bace57f78d27ac13b7229caa56a2e
Re: [transl 7/8] Add pedantic possibilities to the resource page
On 2009.08.14 17:28, Paul Vriens wrote: > Hi, > > Again, passing pedantic in the URL gets a different behavior. In > pedantic mode there will always be a direct comparison with English(US) > when there are warnings. > > Changelog > Add pedantic possibilities to the resource page > You forgot the patch
Re: 2/2 winex11: add XRender based GetSrcAreaStretch
On 07/11/2009 10:08 PM, Roderick Colenbrander wrote: > Hi, > > This patch adds a XRender based GetSrcAreaStretch. A lot of work is > offloaded to X (less round trips are needed) and it can take advantage > of hardware acceleration. On Nvidia and AMD drivers blt performance > has improved by 20% in CrystalMark2004 while more optimizations can be > added later on. I get a similar performance increase on intel driver too.
Re: comctl32: Fix dialog ('Next' button was hidden)
On 07/08/2009 10:31 PM, Frédéric Delanoy wrote: > I think it should be under the button "Finish", so that the "Finish" button can be shown in the same place instead of "Next >" on the last wizard page.
What's with winetest-latest?
I get this Error: "Can't enumerate test files: 1813". And from test.winehq.org looks like everyone is getting an error.
Re: How to test cryptui's dialogs?
On 07/06/2009 03:44 AM, Juan Lang wrote:
> Hi Aurimas,
>
>> But how can I run cryptui's wizards and other dialogs to confirm that
>> everything else is translated correctly?
>
> In addition to the excellent suggestions you've already gotten, I'll
> just add that it's possible to test cryptui's dialogs without
> installing anything by opening the certificate manager. For instance,
> the following program, compiled with winegcc, should produce a program
> that'll open the certificate manager:
>
> #include
> #include
> int main(void)
> {
> CRYPTUI_CERT_MGR_STRUCT mgrStruct;
>
> memset(&mgrStruct, 0, sizeof(mgrStruct);
> mgrStruct.dwSize = sizeof(mgrStruct);
> CryptUIDlgCertMgr(&mgrStruct);
> return 0;
> }
>
> Thanks,
> --Juan
>
Thanks. This method works too.
However, had to add
#include
to compile it.
Unfortunately certificate manager crashes in the same places as it
crashed in Chrome.
Re: [cryptui] Show the select store text when browsing stores
On 07/05/2009 04:08 PM, Paul Vriens wrote: > Hi, > > We at least see the text now. Selecting is possible but doesn't work > (regression?). > > Changelog > Show the select store text when browsing stores > > > > > > +selectInfo.pwszText = LoadStringW(hInstance, IDC_STORE_TEXT, > + storeText, sizeof(storeText) / sizeof(storeText[0])); LoadStringW returns int, not string! LoadStringW(hInstance, IDC_STORE_TEXT, storeText, sizeof(storeText) / sizeof(storeText[0])); selectInfo.pwszText = storeText;
Re: How to test cryptui's dialogs?
On 07/05/2009 01:57 PM, Paul Vriens wrote: > Aurimas Fišeras wrote: >> On 07/05/2009 12:59 PM, Paul Vriens wrote: >>> André Hentschel wrote: >>>> Paul Vriens schrieb: >>>>> On 5 jul 2009, at 09:49, Frédéric Delanoy >>>>> wrote: >>>>> >>>>>> On 07/05/2009 08:46 AM, Aurimas Fišeras wrote: >>>>>>> On 07/05/2009 03:36 AM, Frédéric Delanoy wrote: >>>>>>>> On 07/04/2009 11:29 PM, Aurimas Fišeras wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I've finished translating cryptui's resources, checked control >>>>>>>>> sizes >>>>>>>>> with resource editor and adjusted them where it was needed. >>>>>>>>> >>>>>>>>> But how can I run cryptui's wizards and other dialogs to confirm >>>>>>>>> that >>>>>>>>> everything else is translated correctly? >>>>>>>>> >>>>>>>> You can always run ResHacker (see >>>>>>>> http://wiki.winehq.org/Translating#head-97aa5da9117ce6c05ac70962373f2c3a6a5f81fb >>>>>>>> >>>>>>>> for more information). >>>>>>>> I've used it and it works reasonably well (at least on generated >>>>>>>> *.res files). >>>>>>>> One problem I spotted however (probably a bug in Wine) is that >>>>>>>> you've to use to "All Files (*.*)" filter to view the files. >>>>>>>> >>>>>>> Is I wrote above, I already performed this step (using xnre). Now I >>>>>>> want >>>>>>> to check "live" dialogs, but don't know how. >>>>>> You can do that with ResHacker: just select the dialogs you want to >>>>>> see on the left-side tree, >>>>>> and double-click on the menu you want to check (or single-click and >>>>>> use "show dialog"); what't nice >>>>>> is that you can modify the dialog/widgets sizes and check "live" the >>>>>> results in a preview window. >>>>>> >>>>>> Of course, the buttons won't have any action, but hey, you're >>>>>> translating, not trying to verify that, e.g., >>>>>> the buttons work correctly. >>>>>> >>>>>> If you find a better way, please tell me. >>>>>> >>>>>> Frédéric >>>>> I think I've used Firefox for that.I will check when I've powered up >>>>> my laptop later in the day. >>>>> >>>>> Cheers, >>>>> >>>>> Paul >>>>> >>>> As i wrote the german translation of it, i had the same problem. >>>> The solution is to install IE6 with IEs4Linux or something like that >>>> and go to options->security tab. >>>> You need to check if the installer made a dll-override of cryptui and >>>> the other crypt-things, they should be "built-in". >>>> >>>> Have Fun >>>> Best Regards, André Hentschel >>>> >>>> >>> It wasn't Firefox it was actually Chrome I used for checking the >>> translations. >>> >> Thanks, Chrome worked great for this purpose. > > I'm actually fixing up the NL translations as several things are not > entirely correct (mostly sizing issues). > > I did experience some crashes of Chrome while dealing with the crypt > exporting/importing/viewing, so will do some bughunting as well ;) > Yes I'm having some crashes too. Trying to delete certificate: chrome.exe: context.c:115: Context_GetExtra: Assertion `baseContext->type == ContextTypeLink' failed. Trying to view certificate purposes: chrome.exe: caret.c:183: ME_GetCursorCoordinates: Assertion `~para->member.para.nFlags & 0x01' failed.
Re: How to test cryptui's dialogs?
On 07/05/2009 12:59 PM, Paul Vriens wrote: > André Hentschel wrote: >> Paul Vriens schrieb: >>> On 5 jul 2009, at 09:49, Frédéric Delanoy >>> wrote: >>> >>>> On 07/05/2009 08:46 AM, Aurimas Fišeras wrote: >>>>> On 07/05/2009 03:36 AM, Frédéric Delanoy wrote: >>>>>> On 07/04/2009 11:29 PM, Aurimas Fišeras wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I've finished translating cryptui's resources, checked control sizes >>>>>>> with resource editor and adjusted them where it was needed. >>>>>>> >>>>>>> But how can I run cryptui's wizards and other dialogs to confirm >>>>>>> that >>>>>>> everything else is translated correctly? >>>>>>> >>>>>> You can always run ResHacker (see >>>>>> http://wiki.winehq.org/Translating#head-97aa5da9117ce6c05ac70962373f2c3a6a5f81fb >>>>>> for more information). >>>>>> I've used it and it works reasonably well (at least on generated >>>>>> *.res files). >>>>>> One problem I spotted however (probably a bug in Wine) is that >>>>>> you've to use to "All Files (*.*)" filter to view the files. >>>>>> >>>>> Is I wrote above, I already performed this step (using xnre). Now I >>>>> want >>>>> to check "live" dialogs, but don't know how. >>>> >>>> You can do that with ResHacker: just select the dialogs you want to >>>> see on the left-side tree, >>>> and double-click on the menu you want to check (or single-click and >>>> use "show dialog"); what't nice >>>> is that you can modify the dialog/widgets sizes and check "live" the >>>> results in a preview window. >>>> >>>> Of course, the buttons won't have any action, but hey, you're >>>> translating, not trying to verify that, e.g., >>>> the buttons work correctly. >>>> >>>> If you find a better way, please tell me. >>>> >>>> Frédéric >>> >>> I think I've used Firefox for that.I will check when I've powered up >>> my laptop later in the day. >>> >>> Cheers, >>> >>> Paul >>> >> As i wrote the german translation of it, i had the same problem. >> The solution is to install IE6 with IEs4Linux or something like that >> and go to options->security tab. >> You need to check if the installer made a dll-override of cryptui and >> the other crypt-things, they should be "built-in". >> >> Have Fun >> Best Regards, André Hentschel >> >> > It wasn't Firefox it was actually Chrome I used for checking the > translations. > Thanks, Chrome worked great for this purpose.
Re: How to test cryptui's dialogs?
On 07/05/2009 09:51 AM, Austin English wrote: > 2009/7/5 Aurimas Fišeras : >> On 07/05/2009 03:36 AM, Frédéric Delanoy wrote: >>> On 07/04/2009 11:29 PM, Aurimas Fišeras wrote: >>>> Hello, >>>> >>>> I've finished translating cryptui's resources, checked control sizes >>>> with resource editor and adjusted them where it was needed. >>>> >>>> But how can I run cryptui's wizards and other dialogs to confirm that >>>> everything else is translated correctly? >>>> >>> You can always run ResHacker (see >>> http://wiki.winehq.org/Translating#head-97aa5da9117ce6c05ac70962373f2c3a6a5f81fb >>> for more information). >>> I've used it and it works reasonably well (at least on generated *.res >>> files). >>> One problem I spotted however (probably a bug in Wine) is that you've to >>> use to "All Files (*.*)" filter to view the files. >>> >> Is I wrote above, I already performed this step (using xnre). Now I want >> to check "live" dialogs, but don't know how. > > Isn't that what makefake.sh (http://wiki.winehq.org/Translating) is for? > No, it can be used to check resources in resource editor. What I need is a way to call cryptui.dll's dialogs from some program that uses them.
Re: How to test cryptui's dialogs?
On 07/05/2009 03:36 AM, Frédéric Delanoy wrote: > On 07/04/2009 11:29 PM, Aurimas Fišeras wrote: >> Hello, >> >> I've finished translating cryptui's resources, checked control sizes >> with resource editor and adjusted them where it was needed. >> >> But how can I run cryptui's wizards and other dialogs to confirm that >> everything else is translated correctly? >> > You can always run ResHacker (see > http://wiki.winehq.org/Translating#head-97aa5da9117ce6c05ac70962373f2c3a6a5f81fb > for more information). > I've used it and it works reasonably well (at least on generated *.res files). > One problem I spotted however (probably a bug in Wine) is that you've to use > to "All Files (*.*)" filter to view the files. > Is I wrote above, I already performed this step (using xnre). Now I want to check "live" dialogs, but don't know how.
How to test cryptui's dialogs?
Hello, I've finished translating cryptui's resources, checked control sizes with resource editor and adjusted them where it was needed. But how can I run cryptui's wizards and other dialogs to confirm that everything else is translated correctly?
Re: Wine translation statistics sources
On 2009.06.20 20:19, Alexandre Julliard wrote: > Mikołaj Zalewski writes: > >> It's online again. Having it on WineHQ would probably give a better >> uptime (and a much better latency, but this should also improve on my >> side, when I won't need a temporary SSH tunnel anymore and will move >> the HTTP server from my good old Pentium 100MHz to a new Atom >> machine). I've been in contact with Jeremy Newman about it some time >> ago, but, after a few exchanges, my e-mails got unanswered, so I >> assumed he is too busy to help with it (and, alone, I don't know how >> to do it). > > It's now online at http://source.winehq.org/transl/ and will be updated > every time there's a git push. Please let me know if you find any > problems. The source is also available now in the tools.git repository. > There is a problem with generating a new translation report. http://source.winehq.org/transl/runlog.php: *** programs/winedbg/rsrc.rc [] Could not open ./work/tmp.res ./build-native/tools/wrc/wrc -I./wine/programs/winedbg/ -I./wine/include -I./build-mingw/programs/winedbg/ -I./build-mingw/include --verify-translation ./wine/programs/winedbg/rsrc.rc ./work/tmp.res 2>>./work/run.log >./work/ver.txt
Re: Installing ActivePython screws up PATH in Wine?
On 2009.06.01 08:40, Dan Kegel wrote: > In Wine, I can happily install mingw and add it to the > global PATH by editing the registry key PATH in > [System\\CurrentControlSet\\Control\\Session Manager\\Environment] > > However, once I install ActivePython, something > gets screwed up, and from then on, 'PATH' in CMD > says > PATH="C:\Python26\";;C:\Python26\; > even if I remove that bit from that registry key > and add other directories. > Anyone know what the heck is going on? Maybe it sets PATH as local variable in HKEY_CURRENT_USER/Environment? http://www.winehq.org/docs/wineusr-guide/environment-variables
Re: ntdll: add a warning about running wine as root (resend)
James Mckenzie wrote: > Alexandre Julliard wrote: >[...] > New wine installation: > > su (no dash so root's environment is not picked up) > wine notepad > install various programs and use them. > exit > > User logs in a second time after learning how to properly use Wine. > Attempt to do anything with Wine in user space. Cannot do due to permissions > problems. > > The solution: > > sudo rm -rf .wine No, the solution is sudo chown -R user:user .wine
Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)
Alexandre Julliard wrote:
> Aurimas Fišeras writes:
>
>
>> How to know when to fix NULL pointer dereferences if in most such cases
>> code flow can be traced back to a windows API called by "other program"?
>
> If some other program is really calling it with NULL then you can fix
> it. You can't preemptively fix every API that takes a pointer.
>
OK, I won't "fix" any windows API if no program calls it, although I
don't believe that is right.
But what about this and similar situations?
Error report:
server/debugger.c:160 red Possible NULL dereference of exe_module
Intraprocedural Null error
143: struct process_dll *exe_module = get_process_exe_module( process );
...
160: if (exe_module->file &&
process.h:
static inline struct process_dll *get_process_exe_module( struct process
*process )
{
struct list *ptr = list_head( &process->dlls );
return ptr ? LIST_ENTRY( ptr, struct process_dll, entry ) : NULL;
}
What should I do?
1. change get_process_exe_module() to
return LIST_ENTRY( ptr, struct process_dll, entry );
2. change debugger.c:160 to
if (exe_module && exe_module->file &&
3. inspect list_head()?
4. ignore it?
Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)
Alexandre Julliard wrote: > Aurimas Fišeras writes: > >> Alexandre Julliard wrote: >>> We only want it when an actual app depends on it, otherwise we'd have to >>> add exception handlers in all functions. Note that the Windows behavior >>> often varies across versions too. >>> >> So why are we fixing various "Possible NULL pointer dereference" errors >> reported by Coverity? > > That's different, it's for cases where inspection of the code flow > demonstrates that a NULL dereference can actually happen. In this case > it would mean that some other part of the Wine code calls RegSetValueExA > with a NULL pointer. But that "some other part of Wine" was possibly called from external program via windows API? > Most likely the proper fix would then be in the > caller. > I still don't see the clear difference between these cases. If FunctionA calls FunctionW with (possibly) NULL pointer and FunctionW dereferences it we should fix FunctionA? But since FunctionA is windows API and it is far more likely to be called not from Wine itself but from "other programs", we don't fix neither FunctionA nor FunctionW, but expect that "other programs" will behave and won't call neither FunctionA nor FunctionW (nor FunctionX that calls FunctionA) with NULL pointers? How to know when to fix NULL pointer dereferences if in most such cases code flow can be traced back to a windows API called by "other program"?
Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)
Alexandre Julliard wrote: > Aurimas Fišeras writes: > >> Alexandre Julliard wrote: >>> Of course Windows has exception handlers all over the place, but that >>> doesn't mean we want to replicate that behavior. >> But we want to have a "bug-for-bug" compatibility with Windows? >> Without this patch windows just returns an error, while wine crashes. > > We only want it when an actual app depends on it, otherwise we'd have to > add exception handlers in all functions. Note that the Windows behavior > often varies across versions too. > So why are we fixing various "Possible NULL pointer dereference" errors reported by Coverity?
Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)
Alexandre Julliard wrote: > Rob Shearman writes: > >> 2009/1/26 Aurimas Fišeras : >>> Saturn's error report: >>> (INCONSISTENT USE) Possible null dereference of variable data+(count-1). >>> This variable is checked for Null at lines: registry.c:1051 >>> >>> Tested on Windows XP >>> >>> Changelog: >>>advapi32: Fix potential NULL pointer dereference in RegSetValueExA >>> [with test] (Saturn) >> Excellent, this tool has spotted a corner-case that the code doesn't >> handle correctly. > > I'm not convinced that this is really a bug. If a non-zero count is > specified it's quite reasonable to expect data to be valid. It is also quite reasonable to expect that a function won't crash with all legal parameters. > > Of course Windows has exception handlers all over the place, but that > doesn't mean we want to replicate that behavior. But we want to have a "bug-for-bug" compatibility with Windows? Without this patch windows just returns an error, while wine crashes. There are dozens of similar corner-case errors where Windows crashes as well as wine, but this time only wine crashes.
