Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert M. <rm...@po...> - 2006-06-18 20:50:37
|
Reini Urban wrote: > Robert May schrieb: [snip NotifyIcon test errors] >> To close this issue, Chris re-built with the latest CVS source, and >> everything seems fine. I'm not going to pursue what went on any >> further, unless I see similar reports again. > > For me the new code fixed also these issues. > msvc and cygwin Thank you for the report. Rob. |
|
From: Reini U. <ru...@x-...> - 2006-06-16 06:11:53
|
Robert May schrieb: > Reini Urban wrote: >> Robert May schrieb: >>> Reini Urban wrote: >>>> samples/standard_images.pl is either missing as file in CVS, or >>>> wrongly in MANIFEST. >>>> same for : >>>> win32-gui-demos.pl >>>> Win32-GUI-Constants/TODO >>>> Win32-GUI-Constants/Changes >>> Win32-gui-demos.pl removed (will add again later, when finished) >>> >>> Win32-GUI-Constants/TODO >>> Win32-GUI-Constants/Changes >>> >>> Added. >> Thanks. Builds now almost under cygwin. >> >> 1. samples/standard_images.pl is still in MANIFEST > > Oops. My bad. I'll check in the missing file before the end of the > weekend. thanks. >> 2. In Makefile for gnu make the "-" before cp didn't work for me to copy >> the demos. So I changed that to >> >> demos: >> $(MKPATH) $(INST_DEMO) >> $(CP) samples/*.pl $(INST_DEMO) >> $(CP) samples/*.cur $(INST_DEMO) >> $(CP) samples/*.bmp $(INST_DEMO) >> $(CP) samples/*.ico $(INST_DEMO) >> >> Otherwise the errorlevel is set: >> cp samples/* blib/lib/Win32/GUI/demos >> cp: omitting directory `samples/CVS' >> make: [demos] Error 1 (ignored) > > That look like it is expected to. The "-" before the cp results in the > "(ignored)" on the last line: cp is returning a non-zero exit status, > but make (which would normally abort when this happens), is ignoring it > and continuing. I know that "-" should suppress the make errorlevel breakout. Hmm. Something really weird. > > The files should have all been copied correctly. I'll address a better > way of copying the demo files (similar to that done in the subdirs) in a > future release, but not immediately. > > The changes you propose should not be necessary. > >> 3. gnu make, make test, make install doesn't recurse into the subdirs >> Win32-GUI-AxWindow, Win32-GUI-DIBitmap, Win32-GUI-Grid > > That's by design. None of those 3 modules can be built (as far as I > know) with gcc, as they rely on one or other of the MFC or ATL > frameworks, which only come with MS compilers. Ok, I'll port them then. Shouldn't be that hard to produce import libs on the fly for those MS dll's. Just the names will have to be redecorated. Some .def file munging. http://cygwin.com/faq/faq_3.html#SEC103 -- Reini Urban |
|
From: Reini U. <ru...@x-...> - 2006-06-16 05:55:30
|
Robert May schrieb: > Chris Wearn wrote: >> Hi All, >> >> Building latest CVS source with VC++6, WindowsXP Pro SP2, Perl v5.8.7 >> >> I get the errors listed further below and although there is no error >> message when installing, a previously functioning script which utilises >> NotifyIcon now exhibits the following behaviour… >> >> Custom icon no longer appears ‘set’ on the window entry on the task bar. >> The NotifyIcon does not build and appear in the system tray. It >> generates an error on exit, that it cannot “remove” a resource that is >> not there… >> >> Cheers >> >> Chris Wearn >> >> t\05_NotifyIcon_01_Constructor.....dubious >> Test returned status 11 (wstat 2816, 0xb00) >> DIED. FAILED tests 3, 5-10, 13-16 >> Failed 11/16 tests, 31.25% okay >> t\05_NotifyIcon_02_Change..........dubious >> Test returned status 255 (wstat 65280, 0xff00) >> DIED. FAILED tests 2, 4, 7-16 >> Failed 12/16 tests, 25.00% okay >> t\05_NotifyIcon_03_OtherMethods....dubious >> Test returned status 255 (wstat 65280, 0xff00) >> DIED. FAILED tests 2, 4, 6-9 >> Failed 6/9 tests, 33.33% okay >> t\05_NotifyIcon_04_Remove..........dubious >> Test returned status 255 (wstat 65280, 0xff00) >> DIED. FAILED tests 1, 3-5, 7-9 >> Failed 7/9 tests, 22.22% okay >> t\05_NotifyIcon_05_DESTROY.........dubious >> Test returned status 3 (wstat 768, 0x300) >> DIED. FAILED tests 1, 6-7 >> Failed 3/13 tests, 76.92% okay > > [snip] > > To close this issue, Chris re-built with the latest CVS source, and > everything seems fine. I'm not going to pursue what went on any > further, unless I see similar reports again. For me the new code fixed also these issues. msvc and cygwin -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Robert M. <rm...@po...> - 2006-06-15 23:42:08
|
Robert May wrote: > Reini Urban wrote: >>>> samples/standard_images.pl is either missing as file in CVS, or >>>> wrongly in MANIFEST. >> >> 1. samples/standard_images.pl is still in MANIFEST > > Oops. My bad. I'll check in the missing file before the end of the > weekend. Committed. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2006-06-15 17:35:56
|
Reini Urban wrote: > Robert May schrieb: >> Reini Urban wrote: >>> samples/standard_images.pl is either missing as file in CVS, or >>> wrongly in MANIFEST. >>> same for : >>> win32-gui-demos.pl >>> Win32-GUI-Constants/TODO >>> Win32-GUI-Constants/Changes >> Win32-gui-demos.pl removed (will add again later, when finished) >> >> Win32-GUI-Constants/TODO >> Win32-GUI-Constants/Changes >> >> Added. > > Thanks. Builds now almost under cygwin. > > 1. samples/standard_images.pl is still in MANIFEST Oops. My bad. I'll check in the missing file before the end of the weekend. > 2. In Makefile for gnu make the "-" before cp didn't work for me to copy > the demos. So I changed that to > > demos: > $(MKPATH) $(INST_DEMO) > $(CP) samples/*.pl $(INST_DEMO) > $(CP) samples/*.cur $(INST_DEMO) > $(CP) samples/*.bmp $(INST_DEMO) > $(CP) samples/*.ico $(INST_DEMO) > > Otherwise the errorlevel is set: > cp samples/* blib/lib/Win32/GUI/demos > cp: omitting directory `samples/CVS' > make: [demos] Error 1 (ignored) That look like it is expected to. The "-" before the cp results in the "(ignored)" on the last line: cp is returning a non-zero exit status, but make (which would normally abort when this happens), is ignoring it and continuing. The files should have all been copied correctly. I'll address a better way of copying the demo files (similar to that done in the subdirs) in a future release, but not immediately. The changes you propose should not be necessary. > 3. gnu make, make test, make install doesn't recurse into the subdirs > Win32-GUI-AxWindow, Win32-GUI-DIBitmap, Win32-GUI-Grid That's by design. None of those 3 modules can be built (as far as I know) with gcc, as they rely on one or other of the MFC or ATL frameworks, which only come with MS compilers. You should have a message during the 'perl Makefile.PL' stage that these modules will be skipped during the build. If not, then check the very latest CVS, as there was a bug where I wasn't closing a file descriptor properly, resulting in those messages disappearing into a file I had been writing earlier. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2006-06-15 17:29:23
|
Chris Wearn wrote: > Hi All, >=20 > Building latest CVS source with VC++6, WindowsXP Pro SP2, Perl v5.8.7 >=20 > I get the errors listed further below and although there is no error=20 > message when installing, a previously functioning script which utilises= =20 > NotifyIcon now exhibits the following behaviour=85 >=20 > Custom icon no longer appears =91set=92 on the window entry on the task= bar.=20 > The NotifyIcon does not build and appear in the system tray. It=20 > generates an error on exit, that it cannot =93remove=94 a resource that= is=20 > not there=85 >=20 > Cheers >=20 > Chris Wearn >=20 > t\05_NotifyIcon_01_Constructor.....dubious > Test returned status 11 (wstat 2816, 0xb00) > DIED. FAILED tests 3, 5-10, 13-16 > Failed 11/16 tests, 31.25% okay > t\05_NotifyIcon_02_Change..........dubious > Test returned status 255 (wstat 65280, 0xff00) > DIED. FAILED tests 2, 4, 7-16 > Failed 12/16 tests, 25.00% okay > t\05_NotifyIcon_03_OtherMethods....dubious > Test returned status 255 (wstat 65280, 0xff00) > DIED. FAILED tests 2, 4, 6-9 > Failed 6/9 tests, 33.33% okay > t\05_NotifyIcon_04_Remove..........dubious > Test returned status 255 (wstat 65280, 0xff00) > DIED. FAILED tests 1, 3-5, 7-9 > Failed 7/9 tests, 22.22% okay > t\05_NotifyIcon_05_DESTROY.........dubious > Test returned status 3 (wstat 768, 0x300) > DIED. FAILED tests 1, 6-7 > Failed 3/13 tests, 76.92% okay [snip] To close this issue, Chris re-built with the latest CVS source, and=20 everything seems fine. I'm not going to pursue what went on any=20 further, unless I see similar reports again. Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2006-06-15 11:02:36
|
Robert May schrieb: > Reini Urban wrote: >> samples/standard_images.pl is either missing as file in CVS, or >> wrongly in MANIFEST. >> same for : >> win32-gui-demos.pl >> Win32-GUI-Constants/TODO >> Win32-GUI-Constants/Changes > > Win32-gui-demos.pl removed (will add again later, when finished) > > Win32-GUI-Constants/TODO > Win32-GUI-Constants/Changes > > Added. Thanks. Builds now almost under cygwin. 1. samples/standard_images.pl is still in MANIFEST 2. In Makefile for gnu make the "-" before cp didn't work for me to copy the demos. So I changed that to demos: $(MKPATH) $(INST_DEMO) $(CP) samples/*.pl $(INST_DEMO) $(CP) samples/*.cur $(INST_DEMO) $(CP) samples/*.bmp $(INST_DEMO) $(CP) samples/*.ico $(INST_DEMO) Otherwise the errorlevel is set: cp samples/* blib/lib/Win32/GUI/demos cp: omitting directory `samples/CVS' make: [demos] Error 1 (ignored) 3. gnu make, make test, make install doesn't recurse into the subdirs Win32-GUI-AxWindow, Win32-GUI-DIBitmap, Win32-GUI-Grid |
|
From: Robert M. <rm...@po...> - 2006-06-14 22:27:38
|
Reini Urban wrote: > samples/standard_images.pl is either missing as file in CVS, or > wrongly in MANIFEST. > same for : > win32-gui-demos.pl > Win32-GUI-Constants/TODO > Win32-GUI-Constants/Changes Win32-gui-demos.pl removed (will add again later, when finished) Win32-GUI-Constants/TODO Win32-GUI-Constants/Changes Added. Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2006-06-14 13:25:54
|
samples/standard_images.pl is either missing as file in CVS, or wrongly in MANIFEST. same for : win32-gui-demos.pl Win32-GUI-Constants/TODO Win32-GUI-Constants/Changes -- Reini |
|
From: Robert M. <rm...@po...> - 2006-06-13 22:42:35
|
Chris Wearn wrote: > Building latest CVS source with VC++6, WindowsXP Pro SP2, Perl v5.8.7 [snip errors from testing] OK, so the NotifyIcon constructor is returning undef, now we just need to find out why. [As an aside, more tests are passing than should, due to the constructor adding information to the parent before it finds out that creation of the notifyicon failed, and then never removing it. This is easily fixed] Chris, Can you tell me what this outputs: perl -MWin32::GUI -e "print $Win32::GUI::NotifyIcon::SHELLDLL_VERSION" Can you search you header files for shellapi.h, and tell me what values you can find in there for the following constants: NOTIFYICONDATA_V1_SIZE NOTIFYICONDATAA_V1_SIZE NOTIFYICONDATAW_V1_SIZE NOTIFYICONDATA_V2_SIZE NOTIFYICONDATAA_V2_SIZE NOTIFYICONDATAW_V2_SIZE Thanks, Rob. |
|
From: Chris W. <ch...@vi...> - 2006-06-13 04:39:03
|
Hi All,
=20
Building latest CVS source with VC++6, WindowsXP Pro SP2, Perl v5.8.7
=20
I get the errors listed further below and although there is no error =
message
when installing, a previously functioning script which utilises =
NotifyIcon
now exhibits the following behaviour=85
=20
Custom icon no longer appears =91set=92 on the window entry on the task =
bar. The
NotifyIcon does not build and appear in the system tray. It generates an
error on exit, that it cannot =93remove=94 a resource that is not =
there=85
=20
Cheers
=20
Chris Wearn
=20
t\05_NotifyIcon_01_Constructor.....dubious
Test returned status 11 (wstat 2816, 0xb00)
DIED. FAILED tests 3, 5-10, 13-16
Failed 11/16 tests, 31.25% okay
t\05_NotifyIcon_02_Change..........dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 2, 4, 7-16
Failed 12/16 tests, 25.00% okay
t\05_NotifyIcon_03_OtherMethods....dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 2, 4, 6-9
Failed 6/9 tests, 33.33% okay
t\05_NotifyIcon_04_Remove..........dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1, 3-5, 7-9
Failed 7/9 tests, 22.22% okay
t\05_NotifyIcon_05_DESTROY.........dubious
Test returned status 3 (wstat 768, 0x300)
DIED. FAILED tests 1, 6-7
Failed 3/13 tests, 76.92% okay
=20
=20
Failed Test Stat Wstat Total Fail Failed List of
Failed
-------------------------------------------------------------------------=
---
---
t\05_NotifyIcon_01_Constructor.t 11 2816 16 11 68.75% 3 5-10
13-16
t\05_NotifyIcon_02_Change.t 255 65280 16 18 112.50% 2 4 =
7-16
t\05_NotifyIcon_03_OtherMethods.t 255 65280 9 10 111.11% 2 4 6-9
t\05_NotifyIcon_04_Remove.t 255 65280 9 10 111.11% 1 3-5 =
7-9
t\05_NotifyIcon_05_DESTROY.t 3 768 13 3 23.08% 1 6-7
=20
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 41)
# $W->AddNotifyIcon creates Win32::GUI::NotifyIcon object isn't =
defined
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 43)
# got: undef
# expected: 'Win32::GUI::NotifyIcon=3DHASH(0x1be2ce0)'
Use of uninitialized value in numeric gt (>) at
t\05_NotifyIcon_01_Constructor.t line 46.
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 46)
Use of uninitialized value in hash element at
t\05_NotifyIcon_01_Constructor.t line 47.
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 47)
Use of uninitialized value in hash element at
t\05_NotifyIcon_01_Constructor.t line 48.
Use of uninitialized value in list assignment at =
C:/Perl/lib/Test/Builder.pm
line 472.
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 48)
# got: undef
# expected: 'NI'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 50)
# got: undef
# expected: 'NI'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 51)
# got: undef
# expected: '29426514'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 65)
# got: undef
# expected: 'Win32::GUI NotifyIcon Test Balloon Tip'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 66)
# got: undef
# expected: 'Win32::GUI NotifyIcon Title'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 67)
# got: undef
# expected: 'error'
=20
# Failed test (t\05_NotifyIcon_01_Constructor.t at line 68)
# got: undef
# expected: '20000'
# Looks like you failed 11 tests of 16.
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 38)
# $W->AddNotifyIcon creates Win32::GUI::NotifyIcon object isn't =
defined
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 40)
# got: undef
# expected: 'Win32::GUI::NotifyIcon=3DHASH(0x1c35808)'
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 54)
# got: undef
# expected: 'Win32::GUI NotifyIcon Test Balloon Tip'
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 55)
# got: undef
# expected: 'Win32::GUI NotifyIcon Title'
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 56)
# got: undef
# expected: 'error'
=20
# Failed test (t\05_NotifyIcon_02_Change.t at line 57)
# got: undef
# expected: '20000'
Can't call method "Change" on unblessed reference at
t\05_NotifyIcon_02_Change.t line 61.
# Looks like you planned 16 tests but only ran 10.
# Looks like your test died just after 10.
=20
# Failed test (t\05_NotifyIcon_03_OtherMethods.t at line 39)
# $W->AddNotifyIcon creates Win32::GUI::NotifyIcon object isn't =
defined
=20
# Failed test (t\05_NotifyIcon_03_OtherMethods.t at line 41)
# got: undef
# expected: 'Win32::GUI::NotifyIcon=3DHASH(0x1c354c4)'
Can't call method "ShowBalloon" on an undefined value at
t\05_NotifyIcon_03_OtherMethods.t line 52.
# Looks like you planned 9 tests but only ran 5.
# Looks like your test died just after 5.
=20
# Failed test (t\05_NotifyIcon_04_Remove.t at line 34)
# $W->AddNotifyIcon creates Test::NotifyIcon object isn't defined
Use of uninitialized value in numeric gt (>) at =
t\05_NotifyIcon_04_Remove.t
line 38.
=20
# Failed test (t\05_NotifyIcon_04_Remove.t at line 38)
Use of uninitialized value in hash element at =
t\05_NotifyIcon_04_Remove.t
line 39.
=20
# Failed test (t\05_NotifyIcon_04_Remove.t at line 39)
Use of uninitialized value in hash element at =
t\05_NotifyIcon_04_Remove.t
line 40.
Use of uninitialized value in list assignment at =
C:/Perl/lib/Test/Builder.pm
line 472.
=20
# Failed test (t\05_NotifyIcon_04_Remove.t at line 40)
# got: undef
# expected: 'NI'
Can't call method "Remove" on unblessed reference at
t\05_NotifyIcon_04_Remove.t line 44.
# Looks like you planned 9 tests but only ran 6.
# Looks like your test died just after 6.
=20
# Failed test (t\05_NotifyIcon_05_DESTROY.t at line 34)
# $W->AddNotifyIcon creates Test::NotifyIcon object isn't defined
Use of uninitialized value in hash element at =
t\05_NotifyIcon_05_DESTROY.t
line 57.
=20
# Failed test (t\05_NotifyIcon_05_DESTROY.t at line 57)
=20
# Failed test (t\05_NotifyIcon_05_DESTROY.t at line 58)
# got: 'HASH(0x1c398ac)'
# expected: 'Test::NotifyIcon=3DHASH(0x1b11d54)'
Use of uninitialized value in hash element at =
t\05_NotifyIcon_05_DESTROY.t
line 67.
# Looks like you failed 3 tests of 13.
Failed 5/23 test scripts, 78.26% okay. 39/480 subtests failed, 91.88% =
okay.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff'
Stop.
=20
=20
--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: =
12/06/2006
=20
|
|
From: Robert M. <rm...@po...> - 2006-06-12 18:03:06
|
Jeremy White wrote: >> See the 'Changes' file in each subdirectory for highlights of any >> significant changes. > > She builds fine for me. Good job. Thanks for the feedback. Do all the tests pass for you? Rob. |
|
From: Jeremy W. <jez...@ho...> - 2006-06-12 09:35:25
|
>See the 'Changes' file in each subdirectory for highlights of any >significant changes. She builds fine for me. Good job. Cheers, jez. |
|
From: Jeremy W. <jez...@ho...> - 2006-06-12 09:07:13
|
> > Right :) I don't pretend to speak for everyone, of course. I was a > > little concerned, though, about Jeremy's comment of sharing stuff that > > isn't presently shared, betweeen sub-modules... I don't know how much > > that is, or if it can be done without making more dependencies or bigger > > hunks of stuff. > >I think Jeremy's comment was about sharing GUI.h (and other headers >etc.) during the build process - not about increasing dependencies >between modules. Yeah, there are also some helper functions that could become "common" across modules - even if they just get defined as macros. Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2006-06-11 21:35:03
|
Glenn Linderman wrote: > On approximately 6/3/2006 3:02 AM, came the following characters from > the keyboard of Robert May: >> Glenn Linderman wrote: >>> I don't care how large the binary distribution of Win32::GUI gets, as >>> long as the pieces I don't use don't get loaded at runtime and are >>> not redistributed by PAR. >> >> We should be OK then :-) > > Right :) I don't pretend to speak for everyone, of course. I was a > little concerned, though, about Jeremy's comment of sharing stuff that > isn't presently shared, betweeen sub-modules... I don't know how much > that is, or if it can be done without making more dependencies or bigger > hunks of stuff. I think Jeremy's comment was about sharing GUI.h (and other headers etc.) during the build process - not about increasing dependencies between modules. Rob. |
|
From: Robert M. <rm...@po...> - 2006-06-11 21:09:20
|
Robert May wrote: > FYI. CVS repository needs some attention. I will try to address this > on Sunday. > > Rob. The repository should be clean now. You'll probably need to do a fresh checkout to get the new modules. Here's the current state of the new modules: AxWindow: won't build except with MSVC. Skipped with a message in other environments. DIBitmap: currently skipped with a message if the compiler is gcc. It should be possible to get it to build under both cygwin and mingw, but I have already spent too much of my time trying to get this to work. If anyone else is interested in pursuing this I can provide notes on where I have got to. Grid: can only be built with MSVC. Skipped with a message in other environments. Scintilla: builds and tests fine with MSVC and Mingw. Builds OK under cygwin, but crashes on entering the dialog phase. I haven't attempted to look at this any further yet. See the 'Changes' file in each subdirectory for highlights of any significant changes. Regards, Rob. > > -------- Original Message -------- > Date: Fri, 09 Jun 2006 12:19:05 -0700 > From: SourceForge.net <no...@so...> > > Support Requests item #1499074, was opened at 2006-06-01 15:18 > Message generated for change (Comment added) made by burley > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1499074&group_id=1 > > Please note that this message will contain a full copy of the comment > thread, > including the initial issue submission, for this request, > not just the latest update. > Category: Project CVS Services > Group: Second Level Support >> Status: Closed > Priority: 7 > Submitted By: Robert May (robertemay) > Assigned to: David Burley (burley) > Summary: CVS repository clean-up: perl-win32-gui > > Initial Comment: > unix project name: perl-win32-gui > > Please can you arrange to move the following > directories (and contents) within the perl-win32-gui > CVS repository: > > /Win32-GUI-AxWindow to /Win32-GUI/Win32-GUI-AxWindow > /Win32-GUI-DIBitmap to /Win32-GUI/Win32-GUI-DIBitmap > /Win32-GUI-Grid to /Win32-GUI/Win32-GUI-Grid > /Win32-GUI-Scintilla to /Win32-GUI/Win32-GUI-Scintilla > > Mant thanks, > Rob. > > ---------------------------------------------------------------------- > > Comment By: David Burley (burley) > Date: 2006-06-09 15:19 > > Message: > Logged In: YES > user_id=597273 > > Greetings, > > Per your request, the specified operation has been carried > out upon your project CVS repository. Should you require further > assistance from the SourceForge.net team, please submit a new > support request. > > NOTE: Changes that we make to your repository may not synchronize > with ViewCVS/Anonymous CVS until you checkin a change to your > developer repository. Be sure to make such a change and wait the > requisite 5 hours before reporting any anomalies regarding > actions we performed for you, unless you are using developer CVS > to verify the action. The CVS delay is documented on the site > status page, here: > > https://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352#strategic_projects > > Thank you, > > SourceForge.net support > > ---------------------------------------------------------------------- > > Comment By: David Burley (burley) > Date: 2006-06-06 15:31 > > Message: > Logged In: YES > user_id=597273 > > Greetings, > > This canned response is used by the SourceForge.net team to > convey information about how this Support Request will be > handled. Please read the entirety of this comment before taking > any further action; information enclosed in this comment will > help you to ensure that you have an excellent support experience. > > The SourceForge.net team takes all reported issues seriously; we > will work to provide you a complete, accurate, and timely > response to your inquiry. Information about our support policies > and procedures may be found at: > https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1 > > ABOUT THIS ISSUE: Based on the initial review of this request, we > have determined that this issue will be considered to have High > Priority (this is signified by the summary line we use on this > request, not by the Priority setting on this request). Issues > within this category typically include high-priority issues (such > as CVS repository clean up, CVS stale locks, CVS import > requests, user account issues and support inquiries) related to > the SourceForge.net site or services. A description of this > class of issues may be found at: > https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1#issueclass_high > > TRIAGE PROCESS: The initial review of this issue has resulted in > a member of the SourceForge.net staff determining who should > process this issue, and a change in the Priority, Summary, > Assignee, Group and Category settings for this request. > > WHAT TO EXPECT: Issues of this nature will typically be reviewed > again by the assigned member of the SourceForge.net team within 3 > business days (the SourceForge.net team works at least Monday > through Friday, 9am to 5pm Pacific, excepting holidays), though > most issues of this nature are handled within 24 hours of > submission. Within our next response, we will make a > determination regarding your request, or ask for clarification of > this issue report. Please wait patiently for our next review of, > and response to, this request. > > INQUIRING ABOUT THE STATUS OF THIS ISSUE: Should you have > questions or concerns regarding the status of this issue, simply > add a comment to this support request. All comments you post to > this support request will be received by the SourceForge.net team > member who has been assigned this issue. Please do not submit a > second support request about this issue (add a comment to this > request instead), and do not attempt to contact the assignee of > this request via email; all additional information or comments > about this request should be posted as a comment to this request. > > Thank you, > > SourceForge.net support > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1499074&group_id=1 > > -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
|
From: Robert M. <rm...@po...> - 2006-06-11 20:18:29
|
Reini Urban wrote: > I needed the attached patch to compile Win32-GUI-Constants under > cygwin. > > hash\perfect does not work under the bash, hash/perfect does work > under the bash and under cmd.exe But sadly, not under command.com. I changed this to use $(DIRFILESEP), which MM sets to the correct value, platform dependent. > cygwin IO eol handling leaves a trailing \cM which must be stripped. I applied a different solution, achieving the same end result. Thanks for the report. Additionally I have fixed an incorrect cast in Constants.xs that resulted in some of the constants getting the wrong values (picked up by the tests). Changes will be in CVS shortly. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2006-06-09 22:45:35
|
FYI. CVS repository needs some attention. I will try to address this on Sunday. Rob. -------- Original Message -------- Date: Fri, 09 Jun 2006 12:19:05 -0700 From: SourceForge.net <no...@so...> Support Requests item #1499074, was opened at 2006-06-01 15:18 Message generated for change (Comment added) made by burley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1499074&group_id=1 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Project CVS Services Group: Second Level Support >Status: Closed Priority: 7 Submitted By: Robert May (robertemay) Assigned to: David Burley (burley) Summary: CVS repository clean-up: perl-win32-gui Initial Comment: unix project name: perl-win32-gui Please can you arrange to move the following directories (and contents) within the perl-win32-gui CVS repository: /Win32-GUI-AxWindow to /Win32-GUI/Win32-GUI-AxWindow /Win32-GUI-DIBitmap to /Win32-GUI/Win32-GUI-DIBitmap /Win32-GUI-Grid to /Win32-GUI/Win32-GUI-Grid /Win32-GUI-Scintilla to /Win32-GUI/Win32-GUI-Scintilla Mant thanks, Rob. ---------------------------------------------------------------------- Comment By: David Burley (burley) Date: 2006-06-09 15:19 Message: Logged In: YES user_id=597273 Greetings, Per your request, the specified operation has been carried out upon your project CVS repository. Should you require further assistance from the SourceForge.net team, please submit a new support request. NOTE: Changes that we make to your repository may not synchronize with ViewCVS/Anonymous CVS until you checkin a change to your developer repository. Be sure to make such a change and wait the requisite 5 hours before reporting any anomalies regarding actions we performed for you, unless you are using developer CVS to verify the action. The CVS delay is documented on the site status page, here: https://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352#strategic_projects Thank you, SourceForge.net support ---------------------------------------------------------------------- Comment By: David Burley (burley) Date: 2006-06-06 15:31 Message: Logged In: YES user_id=597273 Greetings, This canned response is used by the SourceForge.net team to convey information about how this Support Request will be handled. Please read the entirety of this comment before taking any further action; information enclosed in this comment will help you to ensure that you have an excellent support experience. The SourceForge.net team takes all reported issues seriously; we will work to provide you a complete, accurate, and timely response to your inquiry. Information about our support policies and procedures may be found at: https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1 ABOUT THIS ISSUE: Based on the initial review of this request, we have determined that this issue will be considered to have High Priority (this is signified by the summary line we use on this request, not by the Priority setting on this request). Issues within this category typically include high-priority issues (such as CVS repository clean up, CVS stale locks, CVS import requests, user account issues and support inquiries) related to the SourceForge.net site or services. A description of this class of issues may be found at: https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1#issueclass_high TRIAGE PROCESS: The initial review of this issue has resulted in a member of the SourceForge.net staff determining who should process this issue, and a change in the Priority, Summary, Assignee, Group and Category settings for this request. WHAT TO EXPECT: Issues of this nature will typically be reviewed again by the assigned member of the SourceForge.net team within 3 business days (the SourceForge.net team works at least Monday through Friday, 9am to 5pm Pacific, excepting holidays), though most issues of this nature are handled within 24 hours of submission. Within our next response, we will make a determination regarding your request, or ask for clarification of this issue report. Please wait patiently for our next review of, and response to, this request. INQUIRING ABOUT THE STATUS OF THIS ISSUE: Should you have questions or concerns regarding the status of this issue, simply add a comment to this support request. All comments you post to this support request will be received by the SourceForge.net team member who has been assigned this issue. Please do not submit a second support request about this issue (add a comment to this request instead), and do not attempt to contact the assignee of this request via email; all additional information or comments about this request should be posted as a comment to this request. Thank you, SourceForge.net support ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1499074&group_id=1 -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
|
From: Reini U. <ru...@x-...> - 2006-06-09 11:22:49
|
I needed the attached patch to compile Win32-GUI-Constants under cygwin. hash\perfect does not work under the bash, hash/perfect does work under the bash and under cmd.exe cygwin IO eol handling leaves a trailing \cM which must be stripped. -- Reini |
|
From: Robert M. <rm...@po...> - 2006-06-08 21:02:59
|
Reini Urban wrote: >> Robert May schrieb: >> ... >> If only there was a way to ask AllocWindow() to create a hidden console [huge snip] > perl2app --gui / pp --gui created apps, have no console. > So I create them with AllocConsole or CreateProcess and > redirect STDERR/STDOUT to this window, and display it only when requested. Can I check I understand what you are saying here: (1) If I create an app with 'pp --gui', and then run it by clicking the exe, I get my window app, without a console. (2) At some point in my program I want to use print() to output a text string. (2) I understand how, at that point, I can use AllocConsole(), along with a redirection of STDOUT to get the print()ed output to appear on a console. (3) Now, say that I don't want to show the console when I create it - there is no way to achieve this with AllocConsole(), so I create the console, and immediately hide it, but get a console 'flash'. You seen to be saying that I can use CreateProcess() to create a console that I can then redirect STD(IN|OUT|ERR) to in order to see my output. If so, then can you give me a bit more detail about the CreateProcess mechanism you use here. I don't understand what I would pass as the CreateProcess() parameters to achieve this. > To work around the flashing issue I can > 1) create it only when requested, but then I loose the previous output, I intend that Win32::GUI::Console will have an "on-demand" mechanism to create a console when the first write to STD(OUT|ERR) happens. Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2006-06-08 07:09:18
|
2006/6/7, Robert May <rm...@po...>: > Glenn Linderman wrote: > > On approximately 6/6/2006 2:08 PM, came the following characters from > > the keyboard of Robert May: > >> Reini Urban wrote: > >>> Robert May schrieb: > >>> ... > >>>> If only there was a way to ask AllocWindow() to create a hidden console, > >>>> but I read that it's impossible. (I do want to explore the possibility > >>>> of using a global hook to see if I can catch one of the messages that > >>>> happens early during window creation, and fiddle the WS_VISIBLE style, > >>>> but I'm not hopeful!) > > I can confirm that as I read elsewhere, it does not seem possible to > either subclass or hook (SetWindowsHookEx(WH_CBT, ...)) a console window. > > >>> You can create it offscreen, to the right or left. > >>> So you can use CreateProcess() with > >>> dwCreationFlags += CREATE_NEW_CONSOLE, instead of AllocConsole() > >>> > >>> And STARTUPINFO.dwX holds the offscreen position. > >> Interesting idea, but I don't think I'm following you here. > >> CreateProcess() will create me a new process, and I can't see how I'd > >> read/write to that process's console from my perl script. > >> > >> Regards, > >> Rob. > > > > It seems that Reini's idea might be useful to stop flashing consoles for > > subprograms, but not for the original program? > > That was my thinking too - but perhaps Reini is > hinting at something that I do not understand? No, I mixed it up. perl2app --gui / pp --gui created apps, have no console. So I create them with AllocConsole or CreateProcess and redirect STDERR/STDOUT to this window, and display it only when requested. To work around the flashing issue I can 1) create it only when requested, but then I loose the previous output, 2) or create it hidden or offscreen and show/move it when requested. Menu: View - Messages... But better is to create the app without --gui and hide the console as discussed here. > If you want to start a sub-process hidden, then > Win32::SetChildShowWindow(SW_HIDE); > is probably easier :-) Correct. -- Reini Urban http://phpwiki.org/ http://spacemovie.mur.at/ http://helsinki.at/ |
|
From: Robert M. <rm...@po...> - 2006-06-07 19:21:30
|
Glenn Linderman wrote: > On approximately 6/6/2006 2:08 PM, came the following characters from > the keyboard of Robert May: >> Reini Urban wrote: >>> Robert May schrieb: >>> ... >>>> If only there was a way to ask AllocWindow() to create a hidden console, >>>> but I read that it's impossible. (I do want to explore the possibility >>>> of using a global hook to see if I can catch one of the messages that >>>> happens early during window creation, and fiddle the WS_VISIBLE style, >>>> but I'm not hopeful!) I can confirm that as I read elsewhere, it does not seem possible to either subclass or hook (SetWindowsHookEx(WH_CBT, ...)) a console window. >>> You can create it offscreen, to the right or left. >>> So you can use CreateProcess() with >>> dwCreationFlags += CREATE_NEW_CONSOLE, instead of AllocConsole() >>> >>> And STARTUPINFO.dwX holds the offscreen position. >> Interesting idea, but I don't think I'm following you here. >> CreateProcess() will create me a new process, and I can't see how I'd >> read/write to that process's console from my perl script. >> >> Regards, >> Rob. > > It seems that Reini's idea might be useful to stop flashing consoles for > subprograms, but not for the original program? That was my thinking too - but perhaps Reini is hinting at something that I do not understand? If you want to start a sub-process hidden, then Win32::SetChildShowWindow(SW_HIDE); is probably easier :-) Rob. |
|
From: Robert M. <rm...@po...> - 2006-06-06 21:08:56
|
Reini Urban wrote: > Robert May schrieb: > ... >> If only there was a way to ask AllocWindow() to create a hidden console, >> but I read that it's impossible. (I do want to explore the possibility >> of using a global hook to see if I can catch one of the messages that >> happens early during window creation, and fiddle the WS_VISIBLE style, >> but I'm not hopeful!) > > You can create it offscreen, to the right or left. > So you can use CreateProcess() with > dwCreationFlags += CREATE_NEW_CONSOLE, instead of AllocConsole() > > And STARTUPINFO.dwX holds the offscreen position. Interesting idea, but I don't think I'm following you here. CreateProcess() will create me a new process, and I can't see how I'd read/write to that process's console from my perl script. Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2006-06-06 05:58:25
|
Robert May schrieb: ... > If only there was a way to ask AllocWindow() to create a hidden console, > but I read that it's impossible. (I do want to explore the possibility > of using a global hook to see if I can catch one of the messages that > happens early during window creation, and fiddle the WS_VISIBLE style, > but I'm not hopeful!) You can create it offscreen, to the right or left. So you can use CreateProcess() with dwCreationFlags += CREATE_NEW_CONSOLE, instead of AllocConsole() And STARTUPINFO.dwX holds the offscreen position. -- Reini Urban http://phpwiki.org/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Robert M. <rm...@po...> - 2006-06-05 23:01:57
|
darrik wrote: > Glenn Linderman wrote: >> I'll >> keep one backup per day-of-the-week so the script chooses the directory >> for the day of the week, and then does your command. So I'll always >> have 7 copies, generally from the last 7 days, and, no doubt, often >> redundant when not much is happening. But only when I'm not on >> vacation, so there will be some sporadic behaviour then, when some of my >> backups could be older... it is part of my bootup-first-time-each-day >> script. > > If it's helpful, I have a linux server running 24/7 at my house, so I > can automate a daily backup and keep them as far back as it suits you > guys (as I'm not in any danger [yet] of filling the 800GBs of disk space > on it). ;) > > I'll set that up Monday at first opportunity. That'd be great. If you'd be willing to automate backing up some other stuff, then drop me a line, and we'll work out what we should be backing up, and how often. Regards, Rob. |
18 messages has been excluded from this view by a project administrator.
