* bug#74312: 31.0.50; Cygw32 build break @ 2024-11-11 14:51 Kazuhiro Ito 2024-11-11 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Kazuhiro Ito @ 2024-11-11 14:51 UTC (permalink / raw) To: 74312 Cygw32 build fails on master $ make (snip) CC w32fns.o ../../../emacs/src/w32fns.c: In function ‘process_dropfiles’: ../../../emacs/src/w32fns.c:2549:17: error: ‘MAX_UTF8_PATH’ undeclared (first use in this function); did you mean ‘MAX_ZONE_PATH’? 2549 | char filename[MAX_UTF8_PATH]; | ^~~~~~~~~~~~~ | MAX_ZONE_PATH ../../../emacs/src/w32fns.c:2549:17: note: each undeclared identifier is reported only once for each function it appears in ../../../emacs/src/w32fns.c:2557:11: warning: implicit declaration of function ‘filename_from_utf16’ [-Wimplicit-function-declaration] 2557 | filename_from_utf16 (p, filename); | ^~~~~~~~~~~~~~~~~~~ ../../../emacs/src/w32fns.c:2557:11: warning: nested extern declaration of ‘filename_from_utf16’ [-Wnested-externs] ../../../emacs/src/w32fns.c:2567:11: warning: implicit declaration of function ‘gifilename_from_ansi’ [-Wimplicit-function-declaration] 2567 | filename_from_ansi (p, filename); | ^~~~~~~~~~~~~~~~~~ ../../../emacs/src/w32fns.c:2567:11: warning: nested extern declaration of ‘filename_from_ansi’ [-Wnested-externs] ../../../emacs/src/w32fns.c:2549:8: warning: unused variable ‘filename’ [-Wunused-variable] 2549 | char filename[MAX_UTF8_PATH]; | ^~~~~~~~ make[2]: *** [Makefile:457: w32fns.o] Error 1 MAX_UTF8_PATH is defined in nt/inc/ms-w32.h and filename_from_* functions are defined in src/w32.c -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-11 14:51 bug#74312: 31.0.50; Cygw32 build break Kazuhiro Ito @ 2024-11-11 16:07 ` Eli Zaretskii 2024-11-11 18:08 ` Ken Brown 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-11-11 16:07 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 74312 > Date: Mon, 11 Nov 2024 23:51:33 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > > Cygw32 build fails on master Thanks, I've tried to fix it, please see if there are other problems. And when it does build, please try the drag-n-drop feature, both with dropping files and with dropping text on Emacs. (I repeatedly asked Ken to test these changes with the Cygwin build, but I guess he didn't yet have time. So it's small wonder that the master branch fails to build on Cygwin.) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-11 16:07 ` Eli Zaretskii @ 2024-11-11 18:08 ` Ken Brown 2024-11-11 20:13 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Ken Brown @ 2024-11-11 18:08 UTC (permalink / raw) To: Eli Zaretskii, Kazuhiro Ito; +Cc: 74312 On 11/11/2024 11:07 AM, Eli Zaretskii wrote: >> Date: Mon, 11 Nov 2024 23:51:33 +0900 >> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> >> >> Cygw32 build fails on master > > Thanks, I've tried to fix it, please see if there are other problems. > And when it does build, please try the drag-n-drop feature, both with > dropping files and with dropping text on Emacs. > > (I repeatedly asked Ken to test these changes with the Cygwin build, > but I guess he didn't yet have time. So it's small wonder that the > master branch fails to build on Cygwin.) I'm sorry, but I somehow missed your requests. I'll try to look at this within the next few days if Kazuhiro doesn't beat me to it. Ken ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-11 18:08 ` Ken Brown @ 2024-11-11 20:13 ` Eli Zaretskii 2024-11-11 22:50 ` Ken Brown 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-11-11 20:13 UTC (permalink / raw) To: Ken Brown; +Cc: kzhr, 74312 > Date: Mon, 11 Nov 2024 13:08:13 -0500 > Cc: 74312@debbugs.gnu.org > From: Ken Brown <kbrown@cornell.edu> > > On 11/11/2024 11:07 AM, Eli Zaretskii wrote: > >> Date: Mon, 11 Nov 2024 23:51:33 +0900 > >> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > >> > >> Cygw32 build fails on master > > > > Thanks, I've tried to fix it, please see if there are other problems. > > And when it does build, please try the drag-n-drop feature, both with > > dropping files and with dropping text on Emacs. > > > > (I repeatedly asked Ken to test these changes with the Cygwin build, > > but I guess he didn't yet have time. So it's small wonder that the > > master branch fails to build on Cygwin.) > > I'm sorry, but I somehow missed your requests. I'll try to look at this > within the next few days if Kazuhiro doesn't beat me to it. Thanks, much appreciated. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-11 20:13 ` Eli Zaretskii @ 2024-11-11 22:50 ` Ken Brown 2024-11-12 12:42 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Ken Brown @ 2024-11-11 22:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kzhr, 74312 On 11/11/2024 3:13 PM, Eli Zaretskii wrote: >> Date: Mon, 11 Nov 2024 13:08:13 -0500 >> Cc: 74312@debbugs.gnu.org >> From: Ken Brown <kbrown@cornell.edu> >> >> On 11/11/2024 11:07 AM, Eli Zaretskii wrote: >>>> Date: Mon, 11 Nov 2024 23:51:33 +0900 >>>> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> >>>> >>>> Cygw32 build fails on master >>> >>> Thanks, I've tried to fix it, please see if there are other problems. >>> And when it does build, please try the drag-n-drop feature, both with >>> dropping files and with dropping text on Emacs. >>> >>> (I repeatedly asked Ken to test these changes with the Cygwin build, >>> but I guess he didn't yet have time. So it's small wonder that the >>> master branch fails to build on Cygwin.) >> >> I'm sorry, but I somehow missed your requests. I'll try to look at this >> within the next few days if Kazuhiro doesn't beat me to it. > > Thanks, much appreciated. The build still fails: In function ‘dump_mm_heap_cb_release’, inlined from ‘dump_mmap_contiguous_heap’ at ../../src/pdumper.c:4919:3, inlined from ‘dump_mmap_contiguous’ at ../../src/pdumper.c:5064:50, inlined from ‘pdumper_load’ at ../../src/pdumper.c:5765:8: ../../src/pdumper.c:4857:11: warning: null pointer dereference [-Wnull-dereference] 4857 | if (--cb->refcount == 0) | ~~^~~~~~~~~~ ../../src/pdumper.c:4857:6: warning: null pointer dereference [-Wnull-dereference] 4857 | if (--cb->refcount == 0) | ^ In file included from ../../src/pdumper.c:26: In function ‘dump_mm_heap_cb_release’, inlined from ‘dump_mm_heap_cb_release’ at ../../src/pdumper.c:4854:1, inlined from ‘dump_mmap_contiguous_heap’ at ../../src/pdumper.c:4919:3, inlined from ‘dump_mmap_contiguous’ at ../../src/pdumper.c:5064:50, inlined from ‘pdumper_load’ at ../../src/pdumper.c:5765:8: ../../src/pdumper.c:4859:7: warning: null pointer dereference [-Wnull-dereference] 4859 | free (cb->mem); | ^ ../../src/w32menu.c: In function ‘w32_popup_dialog’: ../../src/w32menu.c:200:21: warning: implicit declaration of function ‘pMultiByteToWideChar’; did you mean ‘MultiByteToWideChar’? [-Wimplicit-function-declaration] 200 | * pMultiByteToWideChar (CP_UTF8, 0, title, -1, NULL, 0)); | ^~~~~~~~~~~~~~~~~~~~ | MultiByteToWideChar ../../src/w32menu.c:200:21: warning: nested extern declaration of ‘pMultiByteToWideChar’ [-Wnested-externs] ../../src/w32dwrite.c:41: warning: macro "INITGUID" is not used [-Wunused-macros] 41 | # define INITGUID | ../../src/w32dwrite.c: In function ‘w32_dwrite_encode_char’: ../../src/w32dwrite.c:662:51: warning: pointer targets in passing argument 2 of ‘dwrite_font_face->lpVtbl->GetGlyphIndicesA’ differ in signedness [-Wpointer-sign] 662 | &c, 1, &index); | ^~ | | | int * ../../src/w32dwrite.c:662:51: note: expected ‘const UINT32 *’ {aka ‘const unsigned int *’} but argument is of type ‘int *’ /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: w32menu.o: in function `w32_popup_dialog': /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:200:(.text+0xb6a): undefined reference to `pMultiByteToWideChar' /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:202:(.text+0xba5): undefined reference to `pMultiByteToWideChar' /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:252:(.text+0xc1e): undefined reference to `pMultiByteToWideChar' /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:256:(.text+0xc6a): undefined reference to `pMultiByteToWideChar' /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:230:(.text+0xdfe): undefined reference to `pMultiByteToWideChar' /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: w32menu.o:/home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:233: more undefined references to `pMultiByteToWideChar' follow I don't have time right now to look into the reasons for these errors and warnings, but, again, I'll try to do that within a few days if no one beats me to it. Ken ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-11 22:50 ` Ken Brown @ 2024-11-12 12:42 ` Eli Zaretskii 2024-11-12 16:14 ` Kazuhiro Ito 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-11-12 12:42 UTC (permalink / raw) To: Ken Brown; +Cc: kzhr, 74312 > Date: Mon, 11 Nov 2024 17:50:47 -0500 > Cc: kzhr@d1.dion.ne.jp, 74312@debbugs.gnu.org > From: Ken Brown <kbrown@cornell.edu> > > The build still fails: > > In function ‘dump_mm_heap_cb_release’, > inlined from ‘dump_mmap_contiguous_heap’ at ../../src/pdumper.c:4919:3, > inlined from ‘dump_mmap_contiguous’ at ../../src/pdumper.c:5064:50, > inlined from ‘pdumper_load’ at ../../src/pdumper.c:5765:8: > ../../src/pdumper.c:4857:11: warning: null pointer dereference > [-Wnull-dereference] > 4857 | if (--cb->refcount == 0) > | ~~^~~~~~~~~~ > ../../src/pdumper.c:4857:6: warning: null pointer dereference > [-Wnull-dereference] > 4857 | if (--cb->refcount == 0) > | ^ > In file included from ../../src/pdumper.c:26: > In function ‘dump_mm_heap_cb_release’, > inlined from ‘dump_mm_heap_cb_release’ at ../../src/pdumper.c:4854:1, > inlined from ‘dump_mmap_contiguous_heap’ at ../../src/pdumper.c:4919:3, > inlined from ‘dump_mmap_contiguous’ at ../../src/pdumper.c:5064:50, > inlined from ‘pdumper_load’ at ../../src/pdumper.c:5765:8: > ../../src/pdumper.c:4859:7: warning: null pointer dereference > [-Wnull-dereference] > 4859 | free (cb->mem); > | ^ > > ../../src/w32menu.c: In function ‘w32_popup_dialog’: > ../../src/w32menu.c:200:21: warning: implicit declaration of function > ‘pMultiByteToWideChar’; did you mean ‘MultiByteToWideChar’? > [-Wimplicit-function-declaration] > 200 | * pMultiByteToWideChar (CP_UTF8, 0, title, > -1, NULL, 0)); > | ^~~~~~~~~~~~~~~~~~~~ > | MultiByteToWideChar > ../../src/w32menu.c:200:21: warning: nested extern declaration of > ‘pMultiByteToWideChar’ [-Wnested-externs] > > ../../src/w32dwrite.c:41: warning: macro "INITGUID" is not used > [-Wunused-macros] > 41 | # define INITGUID > | > ../../src/w32dwrite.c: In function ‘w32_dwrite_encode_char’: > ../../src/w32dwrite.c:662:51: warning: pointer targets in passing > argument 2 of ‘dwrite_font_face->lpVtbl->GetGlyphIndicesA’ differ in > signedness [-Wpointer-sign] > 662 | &c, 1, &index); > | ^~ > | | > | int * > ../../src/w32dwrite.c:662:51: note: expected ‘const UINT32 *’ {aka > ‘const unsigned int *’} but argument is of type ‘int *’ > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > w32menu.o: in function `w32_popup_dialog': > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:200:(.text+0xb6a): > undefined reference to `pMultiByteToWideChar' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:202:(.text+0xba5): > undefined reference to `pMultiByteToWideChar' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:252:(.text+0xc1e): > undefined reference to `pMultiByteToWideChar' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:256:(.text+0xc6a): > undefined reference to `pMultiByteToWideChar' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:230:(.text+0xdfe): > undefined reference to `pMultiByteToWideChar' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > w32menu.o:/home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:233: > more undefined references to `pMultiByteToWideChar' follow > > I don't have time right now to look into the reasons for these errors > and warnings, but, again, I'll try to do that within a few days if no > one beats me to it. Thanks, I tried to fix those. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-12 12:42 ` Eli Zaretskii @ 2024-11-12 16:14 ` Kazuhiro Ito 2024-11-12 16:47 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Kazuhiro Ito @ 2024-11-12 16:14 UTC (permalink / raw) To: 74312; +Cc: Eli Zaretskii, Ken Brown > > ../../src/w32menu.c: In function ‘w32_popup_dialog’: > > ../../src/w32menu.c:200:21: warning: implicit declaration of function > > ‘pMultiByteToWideChar’; did you mean ‘MultiByteToWideChar’? > > [-Wimplicit-function-declaration] > > 200 | * pMultiByteToWideChar (CP_UTF8, 0, title, > > -1, NULL, 0)); > > | ^~~~~~~~~~~~~~~~~~~~ > > | MultiByteToWideChar > > ../../src/w32menu.c:200:21: warning: nested extern declaration of > > ‘pMultiByteToWideChar’ [-Wnested-externs] > > > > ../../src/w32dwrite.c:41: warning: macro "INITGUID" is not used > > [-Wunused-macros] > > 41 | # define INITGUID > > | > > ../../src/w32dwrite.c: In function ‘w32_dwrite_encode_char’: > > ../../src/w32dwrite.c:662:51: warning: pointer targets in passing > > argument 2 of ‘dwrite_font_face->lpVtbl->GetGlyphIndicesA’ differ in > > signedness [-Wpointer-sign] > > 662 | &c, 1, &index); > > | ^~ > > | | > > | int * > > ../../src/w32dwrite.c:662:51: note: expected ‘const UINT32 *’ {aka > > ‘const unsigned int *’} but argument is of type ‘int *’ > > > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > w32menu.o: in function `w32_popup_dialog': > > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:200:(.text+0xb6a): > > undefined reference to `pMultiByteToWideChar' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:202:(.text+0xba5): > > undefined reference to `pMultiByteToWideChar' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:252:(.text+0xc1e): > > undefined reference to `pMultiByteToWideChar' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:256:(.text+0xc6a): > > undefined reference to `pMultiByteToWideChar' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:230:(.text+0xdfe): > > undefined reference to `pMultiByteToWideChar' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > w32menu.o:/home/kbrown/src/emacs/master/build-w32/src/../../src/w32menu.c:233: > > more undefined references to `pMultiByteToWideChar' follow > > Thanks, I tried to fix those. As far as I tested, modifying your change as below was needed. diff --git a/src/w32menu.c b/src/w32menu.c index b5f87ebb42c..e5415b89bcb 100644 --- a/src/w32menu.c +++ b/src/w32menu.c @@ -187,8 +187,8 @@ task_dialog_callback (HWND hwnd, UINT msg, WPARAM wParam, w32_popup_dialog (struct frame *f, Lisp_Object header, Lisp_Object contents) { #ifdef NTGUI_UNICODE - typedef int (WINAPI *WideCharToMultiByte_Proc)(UINT,DWORD,LPCWSTR,int,LPSTR, - int,LPCSTR,LPBOOL); + typedef int (WINAPI *MultiByteToWideChar_Proc)(UINT,DWORD,LPCSTR,int, + LPWSTR,int); static MultiByteToWideChar_Proc pMultiByteToWideChar = MultiByteToWideChar; #endif /* NTGUI_UNICODE */ check_window_system (f); > And when it does build, please try the drag-n-drop feature, both with > dropping files and with dropping text on Emacs. Dropping multiple files or text works the same as MingW build except files and directories with non-ascii name. When I dragged such files in Emacs frame, mouse cursor changed into red NO ENTRY SIGN (U+1F6AB) and no response for dropping. -- Kazuhiro Ito ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-12 16:14 ` Kazuhiro Ito @ 2024-11-12 16:47 ` Eli Zaretskii 2024-11-13 10:59 ` Kazuhiro Ito 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-11-12 16:47 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: kbrown, 74312 > Date: Wed, 13 Nov 2024 01:14:54 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > Cc: Eli Zaretskii <eliz@gnu.org>, Ken Brown <kbrown@cornell.edu> > > > Thanks, I tried to fix those. > > As far as I tested, modifying your change as below was needed. Thanks, installed. > > And when it does build, please try the drag-n-drop feature, both with > > dropping files and with dropping text on Emacs. > > Dropping multiple files or text works the same as MingW build except > files and directories with non-ascii name. When I dragged such files > in Emacs frame, mouse cursor changed into red NO ENTRY SIGN (U+1F6AB) > and no response for dropping. I guess I didn't understand how are file names dropped into a Cygwin program encoded? Are they in UTF-8, per chance? I assumed that in the Cygw32 build they will be in UTF-16, like for native Windows programs, but maybe that is wrong? Or maybe we should do something on Cygwin to announce that we support dropping files? Did dropping a file or a directory on a Cygw32 Emacs work in previous versions when the file/directory had a non-ASCII name? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-12 16:47 ` Eli Zaretskii @ 2024-11-13 10:59 ` Kazuhiro Ito 2024-11-13 12:33 ` Cecilio Pardo 0 siblings, 1 reply; 16+ messages in thread From: Kazuhiro Ito @ 2024-11-13 10:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kbrown, 74312 > > Dropping multiple files or text works the same as MingW build except > > files and directories with non-ascii name. When I dragged such files > > in Emacs frame, mouse cursor changed into red NO ENTRY SIGN (U+1F6AB) > > and no response for dropping. > > I guess I didn't understand how are file names dropped into a Cygwin > program encoded? Are they in UTF-8, per chance? I assumed that in > the Cygw32 build they will be in UTF-16, like for native Windows > programs, but maybe that is wrong? Or maybe we should do something on > Cygwin to announce that we support dropping files? Ah, sorry, I misinterpretted the result. Cygw32 Emacs can handles non-ascii filename like as MinGW build. Both Emacsen may fail to handle dropped files if I do drag-n-drop files very quickly. I confirmed Microsoft Photo application on Windows 11. And, once Emacs failed to handle drop event, it keeps ignoring dropping files or text event. -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-13 10:59 ` Kazuhiro Ito @ 2024-11-13 12:33 ` Cecilio Pardo 2024-11-13 15:55 ` Kazuhiro Ito 0 siblings, 1 reply; 16+ messages in thread From: Cecilio Pardo @ 2024-11-13 12:33 UTC (permalink / raw) To: 74312 On 13/11/2024 11:59, Kazuhiro Ito wrote: > Both Emacsen may fail to handle dropped files if I do drag-n-drop > files very quickly. I confirmed Microsoft Photo application on > Windows 11. And, once Emacs failed to handle drop event, it keeps > ignoring dropping files or text event. I will look into this. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-13 12:33 ` Cecilio Pardo @ 2024-11-13 15:55 ` Kazuhiro Ito 2024-11-14 8:55 ` Cecilio Pardo 0 siblings, 1 reply; 16+ messages in thread From: Kazuhiro Ito @ 2024-11-13 15:55 UTC (permalink / raw) To: 74312, Cecilio Pardo, Eli Zaretskii > > Both Emacsen may fail to handle dropped files if I do drag-n-drop > > files very quickly. I confirmed Microsoft Photo application on > > Windows 11. And, once Emacs failed to handle drop event, it keeps > > ignoring dropping files or text event. > > I will look into this. As far as I tested, drag-n-drop from Microsoft Photo worked only the first time. Second operation was ignored. Quick operation may fail even at the first time. Drag-n-drop from explorer worked expectedly. -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-13 15:55 ` Kazuhiro Ito @ 2024-11-14 8:55 ` Cecilio Pardo 2024-11-14 9:39 ` Eli Zaretskii 2024-11-14 15:00 ` Kazuhiro Ito 0 siblings, 2 replies; 16+ messages in thread From: Cecilio Pardo @ 2024-11-14 8:55 UTC (permalink / raw) To: Kazuhiro Ito, 74312, Eli Zaretskii On 13/11/2024 16:55, Kazuhiro Ito wrote: >>> Both Emacsen may fail to handle dropped files if I do drag-n-drop >>> files very quickly. I confirmed Microsoft Photo application on >>> Windows 11. And, once Emacs failed to handle drop event, it keeps >>> ignoring dropping files or text event. >> >> I will look into this. > > As far as I tested, drag-n-drop from Microsoft Photo worked only the > first time. Second operation was ignored. Quick operation may fail > even at the first time. Drag-n-drop from explorer worked expectedly. This should fix the Photo application problem. I didn't expect ref counting to be needed for this, my bad. diff --git a/src/w32fns.c b/src/w32fns.c index 1bd3d5099e2..e2455b9271e 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -2562,6 +2562,7 @@ w32_process_dnd_data (int format, void *hGlobal) /* i_drop_target must be the first member. */ IDropTarget i_drop_target; HWND hwnd; + int ref_count; }; static HRESULT STDMETHODCALLTYPE @@ -2573,13 +2574,16 @@ w32_drop_target_QueryInterface (IDropTarget *t, REFIID ri, void **r) static ULONG STDMETHODCALLTYPE w32_drop_target_AddRef (IDropTarget *This) { - return 1; + struct w32_drop_target *target = (struct w32_drop_target *) This; + return ++target->ref_count; } static ULONG STDMETHODCALLTYPE w32_drop_target_Release (IDropTarget *This) { struct w32_drop_target *target = (struct w32_drop_target *) This; + if (--target->ref_count > 0) + return target->ref_count; free (target->i_drop_target.lpVtbl); free (target); return 0; @@ -2770,6 +2774,7 @@ w32_createwindow (struct frame *f, int *coords) if (vtbl != NULL) { drop_target->hwnd = hwnd; + drop_target->ref_count = 0; drop_target->i_drop_target.lpVtbl = vtbl; vtbl->QueryInterface = w32_drop_target_QueryInterface; vtbl->AddRef = w32_drop_target_AddRef; ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-14 8:55 ` Cecilio Pardo @ 2024-11-14 9:39 ` Eli Zaretskii 2024-11-14 10:05 ` Cecilio Pardo 2024-11-14 15:00 ` Kazuhiro Ito 1 sibling, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2024-11-14 9:39 UTC (permalink / raw) To: Cecilio Pardo; +Cc: kzhr, 74312 > Date: Thu, 14 Nov 2024 09:55:56 +0100 > From: Cecilio Pardo <cpardo@imayhem.com> > > On 13/11/2024 16:55, Kazuhiro Ito wrote: > >>> Both Emacsen may fail to handle dropped files if I do drag-n-drop > >>> files very quickly. I confirmed Microsoft Photo application on > >>> Windows 11. And, once Emacs failed to handle drop event, it keeps > >>> ignoring dropping files or text event. > >> > >> I will look into this. > > > > As far as I tested, drag-n-drop from Microsoft Photo worked only the > > first time. Second operation was ignored. Quick operation may fail > > even at the first time. Drag-n-drop from explorer worked expectedly. > > This should fix the Photo application problem. > > I didn't expect ref counting to be needed for this, my bad. Thanks. Can you tell more about the root cause of the problem and how it is solved using reference counting? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-14 9:39 ` Eli Zaretskii @ 2024-11-14 10:05 ` Cecilio Pardo 0 siblings, 0 replies; 16+ messages in thread From: Cecilio Pardo @ 2024-11-14 10:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kzhr, 74312 On 14/11/2024 10:39, Eli Zaretskii wrote: >> This should fix the Photo application problem. >> >> I didn't expect ref counting to be needed for this, my bad. > > Thanks. Can you tell more about the root cause of the problem and how > it is solved using reference counting? w32_drop_target as a COM interface should implement reference counting through the methods AddRef and Release. I didn't implement it (AddRef is a noop, Release frees all always) because I didn't expect to receive any AddRef calls besides the one we get when calling RegisterDragDrop. When dragging files from the Photo application, AddRef and Release are called. The application itselt in principle does not have access to the IDropTarget to call this methods. Or maybe I am very wrong here. In any case, I should have implemented AddRef/Release, and my assumption was wrong. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-14 8:55 ` Cecilio Pardo 2024-11-14 9:39 ` Eli Zaretskii @ 2024-11-14 15:00 ` Kazuhiro Ito 2024-11-14 16:07 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Kazuhiro Ito @ 2024-11-14 15:00 UTC (permalink / raw) To: Cecilio Pardo; +Cc: Eli Zaretskii, 74312 > > As far as I tested, drag-n-drop from Microsoft Photo worked only the > > first time. Second operation was ignored. Quick operation may fail > > even at the first time. Drag-n-drop from explorer worked expectedly. > > This should fix the Photo application problem. I confirmed the problem was fixed, thank you. -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#74312: 31.0.50; Cygw32 build break 2024-11-14 15:00 ` Kazuhiro Ito @ 2024-11-14 16:07 ` Eli Zaretskii 0 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2024-11-14 16:07 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: cpardo, 74312 > Date: Fri, 15 Nov 2024 00:00:40 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > Cc: 74312@debbugs.gnu.org, > Eli Zaretskii <eliz@gnu.org> > > > > As far as I tested, drag-n-drop from Microsoft Photo worked only the > > > first time. Second operation was ignored. Quick operation may fail > > > even at the first time. Drag-n-drop from explorer worked expectedly. > > > > This should fix the Photo application problem. > > I confirmed the problem was fixed, thank you. Thanks for testing, I installed the patch on the master branch. I'm not closing this bug, to let Ken double-check the latest changes and see if something else broke Cygwin. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-11-14 16:07 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-11 14:51 bug#74312: 31.0.50; Cygw32 build break Kazuhiro Ito 2024-11-11 16:07 ` Eli Zaretskii 2024-11-11 18:08 ` Ken Brown 2024-11-11 20:13 ` Eli Zaretskii 2024-11-11 22:50 ` Ken Brown 2024-11-12 12:42 ` Eli Zaretskii 2024-11-12 16:14 ` Kazuhiro Ito 2024-11-12 16:47 ` Eli Zaretskii 2024-11-13 10:59 ` Kazuhiro Ito 2024-11-13 12:33 ` Cecilio Pardo 2024-11-13 15:55 ` Kazuhiro Ito 2024-11-14 8:55 ` Cecilio Pardo 2024-11-14 9:39 ` Eli Zaretskii 2024-11-14 10:05 ` Cecilio Pardo 2024-11-14 15:00 ` Kazuhiro Ito 2024-11-14 16:07 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).