You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
(13) |
Apr
(9) |
May
(22) |
Jun
(70) |
Jul
(10) |
Aug
(57) |
Sep
(35) |
Oct
(33) |
Nov
(61) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(63) |
Feb
(29) |
Mar
(38) |
Apr
(121) |
May
(126) |
Jun
(149) |
Jul
(67) |
Aug
(79) |
Sep
(89) |
Oct
(464) |
Nov
(341) |
Dec
(99) |
2008 |
Jan
(32) |
Feb
(38) |
Mar
(17) |
Apr
(15) |
May
(43) |
Jun
(13) |
Jul
(63) |
Aug
(57) |
Sep
(91) |
Oct
(212) |
Nov
(43) |
Dec
(35) |
2009 |
Jan
(95) |
Feb
(48) |
Mar
(73) |
Apr
(332) |
May
(178) |
Jun
(137) |
Jul
(200) |
Aug
(81) |
Sep
(190) |
Oct
(67) |
Nov
(33) |
Dec
(27) |
2010 |
Jan
(48) |
Feb
(465) |
Mar
(80) |
Apr
(51) |
May
(50) |
Jun
(21) |
Jul
(8) |
Aug
(163) |
Sep
(154) |
Oct
(99) |
Nov
(46) |
Dec
(104) |
2011 |
Jan
(83) |
Feb
(63) |
Mar
(55) |
Apr
(19) |
May
(31) |
Jun
(30) |
Jul
(35) |
Aug
(8) |
Sep
(39) |
Oct
(13) |
Nov
(13) |
Dec
(13) |
2012 |
Jan
(18) |
Feb
(186) |
Mar
(78) |
Apr
(36) |
May
(50) |
Jun
(45) |
Jul
(94) |
Aug
(96) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: SourceForge.net <no...@so...> - 2012-08-03 22:01:47
|
Bugs item #3554117, was opened at 2012-08-03 15:01 Message generated for change (Tracker Item Submitted) made by jeremynicoll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3554117&group_id=119701 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy C B Nicoll (jeremynicoll) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation in rexxhide.exe or rexx.dll Initial Comment: An exec that I run most days just crashed at or near the end of its processing. In its final work before stopping it writes data to a logfile - which worked, as did all the real processing it did before that, then uses RxMessageBox() to display a final summary message - having used the same function many times while running. On this occasion the final summary message was not displayed in a message box, but XP (Pro SP3) reported rexxhide had ended. Dr Watson files are attached, in case they help. As the exec runs most days, and this does not normally happen, I have no idea how to recreate the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3554117&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 19:00:31
|
Bugs item #3542187, was opened at 2012-07-10 14:12 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3542187&group_id=119701 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Nobody/Anonymous (nobody) Summary: Stackspace check on 64-bit platform not large enough Initial Comment: Recursive programs that hit the stack check limit crash trying to raise the error because there's not enough stack space left to process the error. Bumping the limit on the error check appears to fix the problem. I suspect this is only a problem for the 64-bit version. I'm seeing this on Windows, but I suspect other platforms may have the problem too. This simple program can be used to test this: call recurse ::routine recurse call recurse If people see this on other platforms, please comment here. Indicate whether this is 32- or 64-bit. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 12:00 Message: No crash on Fedora 11 64-bit or Ubuntu 32-bit. ---------------------------------------------------------------------- Comment By: Jon Wolfers (sahananda) Date: 2012-07-10 22:26 Message: On Windows 7 32Bit running your script gives: Error 11 running c:\ooRexx\test1.rex line 4: Control stack full Error 11.1: Insufficient control stack space; cannot continue execution Open Object Rexx Version 4.1.0 Build date: Dec 5 2010 Addressing Mode: 32 hth Jon ---------------------------------------------------------------------- Comment By: U. Zinngrebe (uzinngre) Date: 2012-07-10 16:46 Message: No problem on openSuSE 11.4 64 bit - error condition raised properly. test program and console log below uli@ulmo:~/bin> rpm -q ooRexx ooRexx-4.2.0-7988.opensuse1140.x86_64 ------------------------------------- #! /usr/bin/rexx signal on any call recurse say 'no exception' return any: o= .context~condition do i over o~allindexes say left(i,20) o[i] if o[i]~isA(.list) | o[i]~isA(.array) then do say left('',20) o[i]~items 'items' do j over o[i]~allindexes say left('',20) o[i][j] end j end end i return ::routine recurse call recurse ---------------------------------------- uli@ulmo:~/bin> ./test PROPAGATED 1 PROGRAM /home/uli/bin/test PACKAGE a Package CONDITION SYNTAX STACKFRAMES a List 1134 items a StackFrame ... a StackFrame POSITION 24 INSTRUCTION SIGNAL DESCRIPTION CODE 11.1 ADDITIONAL an Array 0 items RC 11 TRACEBACK a List 1134 items 24 *-* call recurse ... 24 *-* call recurse 4 *-* call recurse MESSAGE Insufficient control stack space; cannot continue execution ERRORTEXT Control stack full ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2012-07-10 14:54 Message: Committed revision 8030.-- 4.1 branch Committed revision 8029. -- trunk This fixes only Windows issues. I'll leave this open until we hear from more platforms. ---------------------------------------------------------------------- Comment By: David Ashley (wdashley) Date: 2012-07-10 14:34 Message: No problem on Fedora 17 64 bit. Error condition was raised properly. ooRexx 4.1.1. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2012-07-10 14:34 Message: This doesn't crash with the 32-bit Windows build, so it looks like a 64-bit issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3542187&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 18:58:09
|
Bugs item #2988155, was opened at 2010-04-16 01:41 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2988155&group_id=119701 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: None Group: v4.0 >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: DangerDan (dangerdan) >Assigned to: Mark Miesfeld (miesfeld) Summary: queue use crashes rexx after sysfork child exits Initial Comment: In ooRexx 4.0.0 compiled and run on Slackware Linux 13 (only 64 bit libraries installed), using the SysFork() RexxUtil function sets up the interpreter to crash when the parent process uses a queue after the child (spawned) process exits. #!/opt/ooRexx/bin/rexx PID=sysfork() if PID=0 then do --CHILD say 'bye bye' end; else do --PARENT say 'Queued()='queued(); say 'Queued()='queued(); say 'Hurrah!' queue 'one' parse pull T; say T end exit 0 On Slackware 12 (32 bit Linux) using ooRexx 3.2.0, the exit code is 0 and the result displayed is bye bye Queued()=0 Queued()=0 Hurrah! one With ooRexx 4.0.0, I get an exit code from rexx of 141 and the following display: bye bye Queued()=0 The only work-around I currently have is to create and request a mutex semaphore before the fork and not allow the child process to exit until parent releases it, which curiously doesn't work for ooRexx 3.2.0, because SysRequestMutexSem() could return 0 before the semaphore was released (and possibly before the timeout expired). ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 11:58 Message: Works fine for me under both ooRexx 4.1.1 and under trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2988155&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 18:45:40
|
Bugs item #3509533, was opened at 2012-03-20 17:58 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 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: Classes Group: v4.2.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: U. Zinngrebe (uzinngre) >Assigned to: Mark Miesfeld (miesfeld) Summary: file~lineout(text) must flush to update file Initial Comment: The command sequence in rexxtry.rex (below) shows that the stream must be explicitely flushed in order to write to the file. When several lines are written before flushing, only the first is kept. It causes a test group failure (at the bottom). Tested with openSUSE 11.4 on rev. 7691 and SLES1110 on rev. 7677. Cheers, uli uli@ulmo:~/oorexx/test/trunk> rexxtry.rex REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few... Enter 'exit' to end. file = .stream~new("tmp.txt") ............................................... rexxtry.rex on LINUX file~lineout('a line') ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX call lineout file, 'another line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file rc = 0 ........................................ rexxtry.rex on LINUX say file tmp.txt ............................................... rexxtry.rex on LINUX call lineout 'tmp.txt', 'next line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX say lineout(file,'further line') 0 ............................................... rexxtry.rex on LINUX 'echo $PWD' /home/uli/oorexx/test/trunk rc = 0 ........................................ rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line rc = 0 ........................................ rexxtry.rex on LINUX say file~lineout('last line') 0 ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 17 Mar 21 01:31 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line last line rc = 0 ........................................ rexxtry.rex on LINUX uli@ulmo:~/oorexx/test/trunk> uname -a Linux ulmo 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux uli@ulmo:~/oorexx/test/trunk> rpm -q ooRexx ooRexx-4.2.0-7691.opensuse1140.x86_64 uli@ulmo:~/oorexx/test/trunk> rexx -v Open Object Rexx Version 4.2.0 Build date: Mar 20 2012 Addressing Mode: 64 uli@ulmo:~/oorexx/test/trunk> ./testOORexx.rex -X native_API Searching for test containers... Executing automated test suite........foo ........................... ........... ........................................................................... .......... ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter: REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 Addressing Mode: 64 ooRexxUnit: 2.0.0_3.2.0 ooTest: 1.0.0_4.0.0 Tests ran: 18664 Assertions: 575331 Failures: 1 Errors: 0 Skipped files: 31 [failure] [20120320 23:15:56.161751] svn: r7296 Change date: 2011-11-19 14:37:32 +0100 Test: TEST_FLUSH_ON_CLOSE_XXXXXX Class: Stream.testGroup File: /home/uli/oorexx/test/trunk/ooRexx/base/class/Stream.testGroup Line: 1480 Failed: assertSame Expected: [[first line], identityHash="17540268503362"] Actual: [[The NIL object], identityHash="17540284548842"] File search: 00:00:01.596928 Suite construction: 00:00:01.000005 Test execution: 00:02:13.807635 Total time: 00:02:17.349167 ************************************************* the relvant part of Stream.testGroup: )>1455 -- Regression test for a bug seen at one time. (Don't know the number.) 1456 ::method test_flush_on_close_xxxxxx }>1457 1458 outFile = 'tmpOutDelMe.txt' 1459 rexxPrg = 'tmpPrg' 1460 self~extraTestingFile = rexxPrg || '.rex' 1461 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = "file~lineout('first line') " 1465 src[3] = "file~lineout('second line')" 1466 4>1467 rexxPrg = createRexxPrgFile(src, rexxPrg) .>1468 self~assertNotSame('', rexxPrg) 1469 1>1470 outPut = .array~new 0>1471 ret = execRexxPrg(rexxPrg, outPut) 1472 1473 self~assertSame(0, ret) 8>1474 self~assertTrue(SysIsFile(outFile)) 1475 1476 fsObj = .stream~new(outFile) 1477 self~streamTestingFile = fsObj 1478 1479 text = fsObj~arrayin 1480 self~assertSame('first line', text[1]) 2>1481 self~assertSame('second line', text[2]) 1482 rexxPrg fails to update outFile, and therefore the assertion in line 1480 fails. In the rexxPrg below the lineout function does write into outFile. 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = 'say file~description' 1465 src[3] = "file~lineout('first line') " 1466 src[4] = 'say file~description' 1467 src[5] = "file~lineout('second line')" 1468 src[6] = 'say "file:" file' 1469 src[7] = 'call lineout "'outFile'", "***"' 1470 src[8] = '"echo $PWD"' ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 11:45 Message: Committed revision 8130. This bug was in trunk only, on unix only. I'm closing it now, rather than putting it into pending. The bug actually had nothing to do with the .Stream class, the interpreter instance created in rexx.cpp was not being terminated. I fixed that in Windows, guess I forgot to look at the unix/rexx.cpp. file. Thanks Uli for finding this. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2012-08-03 11:44 Message: Mark, does this fail on Windows too, or just on the unix systems? ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 11:18 Message: Attaching a test program. Fails under 4.2.0 and works fine under 4.1.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 18:44:39
|
Bugs item #3509533, was opened at 2012-03-20 17:58 Message generated for change (Comment added) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 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: Classes Group: v4.2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: U. Zinngrebe (uzinngre) Assigned to: Nobody/Anonymous (nobody) Summary: file~lineout(text) must flush to update file Initial Comment: The command sequence in rexxtry.rex (below) shows that the stream must be explicitely flushed in order to write to the file. When several lines are written before flushing, only the first is kept. It causes a test group failure (at the bottom). Tested with openSUSE 11.4 on rev. 7691 and SLES1110 on rev. 7677. Cheers, uli uli@ulmo:~/oorexx/test/trunk> rexxtry.rex REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few... Enter 'exit' to end. file = .stream~new("tmp.txt") ............................................... rexxtry.rex on LINUX file~lineout('a line') ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX call lineout file, 'another line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file rc = 0 ........................................ rexxtry.rex on LINUX say file tmp.txt ............................................... rexxtry.rex on LINUX call lineout 'tmp.txt', 'next line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX say lineout(file,'further line') 0 ............................................... rexxtry.rex on LINUX 'echo $PWD' /home/uli/oorexx/test/trunk rc = 0 ........................................ rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line rc = 0 ........................................ rexxtry.rex on LINUX say file~lineout('last line') 0 ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 17 Mar 21 01:31 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line last line rc = 0 ........................................ rexxtry.rex on LINUX uli@ulmo:~/oorexx/test/trunk> uname -a Linux ulmo 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux uli@ulmo:~/oorexx/test/trunk> rpm -q ooRexx ooRexx-4.2.0-7691.opensuse1140.x86_64 uli@ulmo:~/oorexx/test/trunk> rexx -v Open Object Rexx Version 4.2.0 Build date: Mar 20 2012 Addressing Mode: 64 uli@ulmo:~/oorexx/test/trunk> ./testOORexx.rex -X native_API Searching for test containers... Executing automated test suite........foo ........................... ........... ........................................................................... .......... ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter: REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 Addressing Mode: 64 ooRexxUnit: 2.0.0_3.2.0 ooTest: 1.0.0_4.0.0 Tests ran: 18664 Assertions: 575331 Failures: 1 Errors: 0 Skipped files: 31 [failure] [20120320 23:15:56.161751] svn: r7296 Change date: 2011-11-19 14:37:32 +0100 Test: TEST_FLUSH_ON_CLOSE_XXXXXX Class: Stream.testGroup File: /home/uli/oorexx/test/trunk/ooRexx/base/class/Stream.testGroup Line: 1480 Failed: assertSame Expected: [[first line], identityHash="17540268503362"] Actual: [[The NIL object], identityHash="17540284548842"] File search: 00:00:01.596928 Suite construction: 00:00:01.000005 Test execution: 00:02:13.807635 Total time: 00:02:17.349167 ************************************************* the relvant part of Stream.testGroup: )>1455 -- Regression test for a bug seen at one time. (Don't know the number.) 1456 ::method test_flush_on_close_xxxxxx }>1457 1458 outFile = 'tmpOutDelMe.txt' 1459 rexxPrg = 'tmpPrg' 1460 self~extraTestingFile = rexxPrg || '.rex' 1461 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = "file~lineout('first line') " 1465 src[3] = "file~lineout('second line')" 1466 4>1467 rexxPrg = createRexxPrgFile(src, rexxPrg) .>1468 self~assertNotSame('', rexxPrg) 1469 1>1470 outPut = .array~new 0>1471 ret = execRexxPrg(rexxPrg, outPut) 1472 1473 self~assertSame(0, ret) 8>1474 self~assertTrue(SysIsFile(outFile)) 1475 1476 fsObj = .stream~new(outFile) 1477 self~streamTestingFile = fsObj 1478 1479 text = fsObj~arrayin 1480 self~assertSame('first line', text[1]) 2>1481 self~assertSame('second line', text[2]) 1482 rexxPrg fails to update outFile, and therefore the assertion in line 1480 fails. In the rexxPrg below the lineout function does write into outFile. 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = 'say file~description' 1465 src[3] = "file~lineout('first line') " 1466 src[4] = 'say file~description' 1467 src[5] = "file~lineout('second line')" 1468 src[6] = 'say "file:" file' 1469 src[7] = 'call lineout "'outFile'", "***"' 1470 src[8] = '"echo $PWD"' ---------------------------------------------------------------------- >Comment By: Rick McGuire (bigrixx) Date: 2012-08-03 11:44 Message: Mark, does this fail on Windows too, or just on the unix systems? ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 11:18 Message: Attaching a test program. Fails under 4.2.0 and works fine under 4.1.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 18:18:30
|
Bugs item #3509533, was opened at 2012-03-20 17:58 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 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: Classes Group: v4.2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: U. Zinngrebe (uzinngre) Assigned to: Nobody/Anonymous (nobody) Summary: file~lineout(text) must flush to update file Initial Comment: The command sequence in rexxtry.rex (below) shows that the stream must be explicitely flushed in order to write to the file. When several lines are written before flushing, only the first is kept. It causes a test group failure (at the bottom). Tested with openSUSE 11.4 on rev. 7691 and SLES1110 on rev. 7677. Cheers, uli uli@ulmo:~/oorexx/test/trunk> rexxtry.rex REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few... Enter 'exit' to end. file = .stream~new("tmp.txt") ............................................... rexxtry.rex on LINUX file~lineout('a line') ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX call lineout file, 'another line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file rc = 0 ........................................ rexxtry.rex on LINUX say file tmp.txt ............................................... rexxtry.rex on LINUX call lineout 'tmp.txt', 'next line' ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~description READY: ............................................... rexxtry.rex on LINUX say lineout(file,'further line') 0 ............................................... rexxtry.rex on LINUX 'echo $PWD' /home/uli/oorexx/test/trunk rc = 0 ........................................ rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 0 Mar 21 01:01 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line rc = 0 ........................................ rexxtry.rex on LINUX say file~lineout('last line') 0 ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 7 Mar 21 01:24 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX say file~flush READY: ............................................... rexxtry.rex on LINUX 'ls -l' file -rw------- 1 uli users 17 Mar 21 01:31 tmp.txt rc = 0 ........................................ rexxtry.rex on LINUX 'cat' file a line last line rc = 0 ........................................ rexxtry.rex on LINUX uli@ulmo:~/oorexx/test/trunk> uname -a Linux ulmo 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux uli@ulmo:~/oorexx/test/trunk> rpm -q ooRexx ooRexx-4.2.0-7691.opensuse1140.x86_64 uli@ulmo:~/oorexx/test/trunk> rexx -v Open Object Rexx Version 4.2.0 Build date: Mar 20 2012 Addressing Mode: 64 uli@ulmo:~/oorexx/test/trunk> ./testOORexx.rex -X native_API Searching for test containers... Executing automated test suite........foo ........................... ........... ........................................................................... .......... ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter: REXX-ooRexx_4.2.0(MT) 6.04 20 Mar 2012 Addressing Mode: 64 ooRexxUnit: 2.0.0_3.2.0 ooTest: 1.0.0_4.0.0 Tests ran: 18664 Assertions: 575331 Failures: 1 Errors: 0 Skipped files: 31 [failure] [20120320 23:15:56.161751] svn: r7296 Change date: 2011-11-19 14:37:32 +0100 Test: TEST_FLUSH_ON_CLOSE_XXXXXX Class: Stream.testGroup File: /home/uli/oorexx/test/trunk/ooRexx/base/class/Stream.testGroup Line: 1480 Failed: assertSame Expected: [[first line], identityHash="17540268503362"] Actual: [[The NIL object], identityHash="17540284548842"] File search: 00:00:01.596928 Suite construction: 00:00:01.000005 Test execution: 00:02:13.807635 Total time: 00:02:17.349167 ************************************************* the relvant part of Stream.testGroup: )>1455 -- Regression test for a bug seen at one time. (Don't know the number.) 1456 ::method test_flush_on_close_xxxxxx }>1457 1458 outFile = 'tmpOutDelMe.txt' 1459 rexxPrg = 'tmpPrg' 1460 self~extraTestingFile = rexxPrg || '.rex' 1461 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = "file~lineout('first line') " 1465 src[3] = "file~lineout('second line')" 1466 4>1467 rexxPrg = createRexxPrgFile(src, rexxPrg) .>1468 self~assertNotSame('', rexxPrg) 1469 1>1470 outPut = .array~new 0>1471 ret = execRexxPrg(rexxPrg, outPut) 1472 1473 self~assertSame(0, ret) 8>1474 self~assertTrue(SysIsFile(outFile)) 1475 1476 fsObj = .stream~new(outFile) 1477 self~streamTestingFile = fsObj 1478 1479 text = fsObj~arrayin 1480 self~assertSame('first line', text[1]) 2>1481 self~assertSame('second line', text[2]) 1482 rexxPrg fails to update outFile, and therefore the assertion in line 1480 fails. In the rexxPrg below the lineout function does write into outFile. 1462 src = .array~new 1463 src[1] = 'file = .stream~new("'outFile'")' 1464 src[2] = 'say file~description' 1465 src[3] = "file~lineout('first line') " 1466 src[4] = 'say file~description' 1467 src[5] = "file~lineout('second line')" 1468 src[6] = 'say "file:" file' 1469 src[7] = 'call lineout "'outFile'", "***"' 1470 src[8] = '"echo $PWD"' ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 11:18 Message: Attaching a test program. Fails under 4.2.0 and works fine under 4.1.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3509533&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:48:05
|
Bugs item #3540480, was opened at 2012-07-05 07:49 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3540480&group_id=119701 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: External Functions Group: v4.0.1 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: PaulD (pdunkl) >Assigned to: Mark Miesfeld (miesfeld) Summary: RxFuncquery broken on SUSE SLES10 SP4 on IBM System Z Initial Comment: RxFuncquery always returns 0 irrespective of registration state of a module. Experiencing on 32-bit exection on SLES10 SP4 on z/Linux (IBM System Z) platform ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 08:48 Message: I'm closing this based on PaulD's latest comments. It is not a bug in RxFuncQuery(). ---------------------------------------------------------------------- Comment By: PaulD (pdunkl) Date: 2012-07-31 11:45 Message: I noticed that now the RxFuncquery() is giving a result other than 0. Strange, and so this time I went looking for more clues. It turned out that RXQUEUE OS queuing function was giving a segmentation fault, and in some cases REX121 errors. Looking up old bug report 2813308 gave me the info I needed to determine that the "rxapi" init.d script was not running. Modifying the simple "test-cmd.rexxx" script to include the following lines; say "RxFuncquery('sqlexec') " RxFuncquery('sqlexec'); say "Rxfuncadd('sqlexec','db2ar','sqlexec') " Rxfuncadd('sqlexec','db2ar','sqlexec'); say "RxFuncquery('sqlexec') " RxFuncquery('sqlexec'); I ran it when the "rxapi" script was down, and then started the script and then ran it again afterwards. The result was as follows: /home/db2admin/vse DBA-1>rexx test-cmd.rexx RxFuncquery('sqlexec') 1 Rxfuncadd('sqlexec','db2ar','sqlexec') 1 RxFuncquery('sqlexec') 1 SQLCA.SQLCODE = SQLCA.SQLCODE SQLCA.SQLCODE = SQLCA.SQLCODE /home/db2admin/vse DBA-1>sudo /etc/init.d/rxapid start Starting rxapi: /home/db2admin/vse DBA-1>rexx test-cmd.rexx RxFuncquery('sqlexec') 1 Rxfuncadd('sqlexec','db2ar','sqlexec') 0 RxFuncquery('sqlexec') 0 SQLCA.SQLCODE = SQLCA.SQLCODE sqlexec() returns ret: 0 SQLCA.SQLCODE = -1024 /home/db2admin/vse DBA-1> SQLCA.SQLCODE = -1024 is expected as it i simply telling me that I did not establish a Database CONNECT session beforehand. If the DB2 function library was not loaded then the SQLCA.SQLCODE variable would be uninitialized. So now the function behaves. It appears that my problems stem from the fact that "rxapi" is not starting up on boot or reboot of the system. I do not know why at the moment as I have used both YaST2 and INSSERV to enable it in the SLES10 on System Z environment. At this point it appears that this may be outside the control of REXX and so I will agree to close this incident. ---------------------------------------------------------------------- Comment By: PaulD (pdunkl) Date: 2012-07-31 09:11 Message: I know you say that my code is backward but it was purposefully done in order to work around the failing of the RxFuncQuery(). In effect I was coding the parts but negating the RxFuncQuery() return value in order to force the correct load of the function using RxFuncAdd(). When the code is stabilized all I need to do is remove the negation. Here is your supplied code snippet. I have modified with parameters needed to make the "sqlexec()" function work; /* ------- Begin code snippet ---------- */ sq1='select * from sysibmadm.dbpaths' say 'SQLCA.SQLCODE = 'SQLCA.SQLCODE; If RxFuncquery('sqlexec') == 0 then do -- Okay sqlexec() is available, call it ret = sqlexec('PREPARE s1 from :sq1') say 'sqlexec() returns ret:' ret end say 'SQLCA.SQLCODE = 'SQLCA.SQLCODE; /* ------- End code snippet ---------- */ Here is the output from that code snippet run; /home/db2admin/vse DBA-1>rexx test-cmd.rexx SQLCA.SQLCODE = SQLCA.SQLCODE SQLCA.SQLCODE = SQLCA.SQLCODE Here is the same code snippet again, but without the '==0' strictly equal object qualifier; /* ------- Begin code snippet(2) ---------- */ sq1='select * from sysibmadm.dbpaths' say 'SQLCA.SQLCODE = 'SQLCA.SQLCODE; If RxFuncquery('sqlexec') then do -- Okay sqlexec() is available, call it ret = sqlexec('PREPARE s1 from :sq1') say 'sqlexec() returns ret:' ret end say 'SQLCA.SQLCODE = 'SQLCA.SQLCODE; /* ------- End code snippet(2) ---------- */ Again the output from the run; /home/db2admin/vse DBA-1>rexx test-cmd.rexx SQLCA.SQLCODE = SQLCA.SQLCODE 23 *-* ret = sqlexec('PREPARE s1 from :sq1') REX0043E: Error 43 running /home/db2admin/vse/test-cmd.rexx line 23: Routine not found REX0417E: Error 43.1: Could not find routine "SQLEXEC" Note that the second method is what is documented in the manual. Do advise on what I may doing incorrectly, or if you need further test output. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-07-20 18:47 Message: The docs for RxFuncQuery() say: Queries the list of available functions for the function name. It returns a value of 0 if the function is registered, and a value of 1 if it is not. So, your logic looks backwards to me. And you're test code snippet doesn't prove anything. In this snippet you have: say \RxFuncquery('sqlexec'); and the output is 1, so RxFuncQuery() is returning 0 saying the function sqlexec() is available. Without seeing an entire program, I'd say okay, you asked if the function is available and RxFuncQuery() says it is. What happens if you write this code: If RxFuncquery('sqlexec') == 0 then do -- Okay sqlexec() is available, call it ret = sqlexec(<fill in arguments, I don't know them>) say 'sqlexec() returns ret:' ret end If you demonstrate that RxFuncQuery() returns 0 saying a function is available, but it is NOT available, then I'd say that was a bug. All you've shown here is that the interpreter says sqlexec() is available. So, I'd have to assume it is available. ---------------------------------------------------------------------- Comment By: PaulD (pdunkl) Date: 2012-07-05 08:04 Message: Need to run DB2 Database interface from REXX but the interface is 32-bit code. Therefore had to rebuild rpms from source to create 32-bit execution: /home/db2admin/vse DBA-2>rexx -version Open Object Rexx Version 4.0.1 Build date: Jul 3 2012 Addressing Mode: 32 Copyright (c) IBM Corporation 1995, 2004. Copyright (c) RexxLA 2005-2009. All Rights Reserved. This program and the accompanying materials are made available under the terms of the Common Public License v1.0 which accompanies this distribution. http://www.oorexx.org/license.html /home/db2admin/vse DBA-2> After install of rpm file I had to issue the following command to move the location of the installed libarary modules links: sudo mv /usr/lib64/librexx* /usr/lib/ before I could get access to the DB2 module function, namely "/opt/IBM/db2/V9.5/lib32/libdb2ar.so" in my case. When I run the following bit of code: ... If \RxFuncquery('sqlexec') Then If Rxfuncadd('sqlexec','db2ar','sqlexec') Then do; say "Unable to load sqlexec function"; /* Return */; end; say 'sqlexec'; say \RxFuncquery('sqlexec'); say Rxfuncadd('sqlexec','db2ar','sqlexec') ; say \RxFuncquery('sqlexec'); ... I get the following result: sqlexec 1 0 1 The RxFuncquery function is not working according to the doc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3540480&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:43:46
|
Bugs item #3284363, was opened at 2011-04-11 03:42 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3284363&group_id=119701 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: None Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Gon Igartua (braviss) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault (core dumped) Initial Comment: Hi, I have this Segmentation fault every days in several machines. I attach log and dump. Thanks ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-03 08:43 Message: While we always encourage people to report bugs, a bug report like this is practically worthless to us. At the very least you need to: list the version of ooRexx in use, the operating system the crash occurs on, describe what is happening, in detail, when the seg fault happens, and describe in some way how to reproduce the bug. You should also attach a Rexx program that can be used to reproduce the bug. While there are a very few bugs where attaching a program may not be possible, in almost all cases it is. In addition, although the attached log appears legitimate this: "Here is the dump http://ftp.blogdrake.net/incoming/core.8990" appears to be either spam or a phishing attempt. Because of that I intend to close this in a month unless Go Igartua replies back with some usable information. -- Mark Miesfeld ---------------------------------------------------------------------- Comment By: Gon Igartua (braviss) Date: 2011-04-11 03:53 Message: Here is the dump http://ftp.blogdrake.net/incoming/core.8990 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3284363&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:23
|
Bugs item #2533788, was opened at 2009-01-24 12:59 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2533788&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog can create wrong object type for controls Initial Comment: This is intended for a post-4.0.0 fix. The way the ooDialog code is structured makes it easy to create the wrong ooDialog class instance for dialog controls. An ooDialog dialog control object is created from the resource ID and what the programmer says the object is. For instance: rb = self~getRadioControl(400) to get a RadioButton object. But, if the 400 ID is actually the ID of say, a list-view control, then we end up with an object that has the methods of a RadioButton object, but actually maps to list-view control. This causes incorrect results for most method invocations on the object, to say the least. ooDialog already has the paradigm of returning .nil for a request to 'get' some type of control when the request is made before the underlying dialog has been created. With the new APIs this can be easily extended to check that the underlying dialog control will actually map to the ooDialog object requested. Return .nil if it doesn't. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 06:54 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:12 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-07-13 17:29 Message: Committed revision 4913. Moved all of the 'getControl' logic of the AdvancedControls class into a native API method. That way, the code has access to the real type of the underlying Window control If the actual type does not match the requested type, then .nil is returned. This is logically the same as the user requesting a control with an invalid resource ID. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2533788&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:19
|
Bugs item #2807760, was opened at 2009-06-17 08:06 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2807760&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - some event connection methods incorrect Initial Comment: In ooDialog you can connect a Windows event to a method in a ooRexx dialog class. When the Windows event happens, the method in the dialog is invoked. Several of the internal methods related to this are allowing the empty string to be used as the method name. This of course doesn't work. In addition, in the doc the railroad track diagram for some of the methods indicates that the method name is optional, although the text itself doesn't indicate that. The method name can not be optional. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:15 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-07-03 18:35 Message: Committed revision 4872. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-06-17 09:24 Message: Rick, As far as the empty string goes for a method name, the C code that implements the invocation of the ooRexx method, would just generate an error. You'd end up with something similar to: interpret '(234459, 89223)' the way the code is. So, all in all, I think this was just a mistake in implementation, not something intentional. Although, I'm glad you reminded me that "" is a valid method name, hopefully it will sink in. Because it seems to me you reminded me of that in the past. <grin> ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-06-17 08:38 Message: Hmmm, ... well thanks Rick. You're right in assuming I had not considered that. I don't think this was the intent here, because in the implementing C code they checked for the empty string and rejected it. Returned an error code and did not connect the event to a method a name of "". The original code: if (!prog.strlength) return 0; In the couple of methods where the doc seems to indicate that the method name argument is optional, the code does not check that it is ommitted, it just uses the argument name. So in those cases, the method invoked would be the argument name. Which in one case would be msgToRise and in another case msgToRaise. Since this isn't documented, it would take a pretty savy user to understand what method they are suppossed to implement. And, there is a related bug, which I didn't spell out - trying not to be too wordy. When a dialog template is created from parsing a .rc script file, the user can specify to automatically connect buttons to a method. Using the CONNECTBUTTONS option. The code essentially goes: if connectbuttons then self~connectButton(id, methodname) else self~connectButton(id) I just don't think that is intentional, because the else statement would just return an error code. I'll put some more thought into what changes I make. <grin> ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-06-17 08:08 Message: I'm not sure I understand all of the specifics here, but a "" string IS a valid ooRexx method name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2807760&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:14
|
Bugs item #2855771, was opened at 2009-09-09 21:32 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2855771&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: The StaticControl~setIcon() method may crash Initial Comment: There is a bug in the .Image class in ooDialog that will cause a crash if wrong arguments are supplied when creating a new Icon image. This could show up for instance in a method like setIcon of the static control A work around would be to not use wrong arguments when creating an icon image. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:18 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 09:03 Message: This is fixed in trunk since revision 5162. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-25 17:54 Message: The fix for this will need to be deferred, it is too intertwined with other ooDialog changes. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-09 21:44 Message: Committed revision 5162. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2855771&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:10
|
Bugs item #2869326, was opened at 2009-09-28 16:55 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869326&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooticket.rex sample has bug setting days Initial Comment: In the ooticke.rex sample, an ooDialog sample, the dialog is supposed to set the radio button in the 'Days' radio button to the current day. This only works if the current day is Sunday. In a CategoryDialog, which this example is, all dialog controls on all of the pages have to have an unique ID. If they do not, the "setData" / "getData" methods are not guarenteed to work. The sample uses the same resource IDs for the radio buttons on the 'Days' page as it does for some of the controls on the 'Movies' page, which causes this bug. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-28 16:56 Message: Committed revision 5219. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869326&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:09
|
Bugs item #2869333, was opened at 2009-09-28 17:04 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869333&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - build.rex out of date Initial Comment: The distribution includes a file build.rex and places it in samples\oodialog\source. This file is way out of date and should either be brought up to date, or removed from the distribution. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 16:19 Message: Committed revision 6094. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869333&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:04
|
Bugs item #2876376, was opened at 2009-10-10 15:15 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2876376&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog "clear" methods broken Initial Comment: ooDialog has a number of methods used to "clear" areas of windows. The "clear" operation is actually the painting of a rectangle in the window with a background brush. This has the effect of erasing the area of the rectangle. 1.) The wrong system brush is used, so the areas do not look "cleared.' 2.) More importantly, for a number of the methods, the rectangle that is actually cleared is obviously not the correct rectangle. The attached program easily demonstrates this. To compound this problem, the current documentation for these methods is vague. This makes it very difficult to know for sure what the methods are intended to do. In Windows, each window has two areas. One is the entire rectangle the window takes up. The other is the "client" area. The client area is for drawing, and normally programs would never draw outside the client area. The MSDN docs suggest that you should never draw in the non-client area of a window: "Painting in nonclient areas of any window is not recommended." Because of this, I'm going to take the stance that the methods were intended to clear rectangles within the client area of a window. Since, I don't see that ooDialog provides a way to draw in the non-client area of a window, this seems to make the most sense. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 12:38 Message: This is fixed in trunk during the refactoring of ooDialog. The fix will be present in the next major release of ooDialog ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-10-10 15:29 Message: Small update to example so it runs under 3.2.0 and demonstrates the bug existed prior to 4.0.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2876376&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:03
|
Bugs item #2876625, was opened at 2009-10-11 13:22 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2876625&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - move() and resize() methods broken Initial Comment: In ooDialog there are methods to move a dialog (or dialog control) and methods to resize a dialog (or dialog control). These methods are broken and neither resize nor move correctly. Attached is an example program that demostrates this. By using the program along with Microsoft's Spy++ which shows the actual size and position of any window on the system it is easily verified that resizing or moving dialogs under ooRexx 4.0.0 and earlier does not produce correct results. Even if Spy++ is not available, the example program prints out the expected size or new position and the actual. This also shows that the results are incorrect. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 12:31 Message: This is fixed in trunk by the addition of the moveTo() and resizeTo() methods which work correctly. These methods will be in the next major release of ooDialog ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2876625&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:02
|
Bugs item #2887675, was opened at 2009-10-27 20:26 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2887675&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - listBox~insert can crash, etc.. Initial Comment: The insert() method of the .ListBox class has several problems. One of which is that it can crash the interpreter under 3.2.0 and can produce very bizarre behavior under 4.0.0 . An example program that demonstrates this is attached. In addition, the method is documented as inserting the item *after* the selected item, if the index argument is omitted. However, it usually inserts before the selected item, often inserts at a point that has no relation to the selected item, and rarely inserts after the item. In the next release, I was going to simply mimic the previous behavior, even though it is nonsensical. However, because I can crash 3.2.0, I'm going to treat this behavior as a bug and fix the method to behave as documented. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 12:26 Message: This is fixed in trunk. The fix will be present in the next major release of ooDialog. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2887675&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:13:01
|
Bugs item #2924424, was opened at 2009-12-31 22:05 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2924424&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog internal logic wrong on failed dialog creation Initial Comment: In ooDialog, when there is a failure to create the underlying Windows dialog, there is some clean up of the internal data structures that needs to be down. (At this time namely the DIALOGADMIN block.) The logic in this area is incorrect, it actually deletes the data structures of the previously created dialog, and fails to delete the data structures of failed dialog. If only one dialog has been created, there is no way for the user to see this error. But, if two dialogs are created in a row, with the second dialog having an error, the the first dialog is destroyed. This of course makes it easy to see that something is wrong. The attached program demonstrates this error on 3.2.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 07:15 Message: This is fixed in trunk, fixed durning the refactoring of ooDialog. The demonstration program runs correctly under an ooRexx built from trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2924424&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:12:56
|
Bugs item #2969512, was opened at 2010-03-12 08:48 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2969512&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - addAttribute has bug Initial Comment: ooDialog has a feature where, for each control in a dialog, an attribute is added to the Rexx dialog object to reflect the 'value' of the dialog control. In most cases, the attribute name is automaticaly generated, sometimes supplied by the programmer. In either case, the implementing code has checks to ensure that the new attribute name is a valid method name and not a duplicate of an existing method in the object. If so an alternative name is automatically generated. The code to do the checks is flawed as the attached program demonstrates. In this code snippet each of the check box controls will have a generated attribute name that is an existing method name of the dialog object: copy, defaultName, and class. For all 3 check boxes, the alternative name should be generated. But, as the example program shows, this does not work correctly for the "copy" and "default name" check boxes. self~addCheckBox(IDC_CHK_COPY, , 10, 10, 80, 12, "&Copy", "GROUP") self~addCheckBox(IDC_CHK_DEFAULTNAME, , 10, 27, 80, 12, "Default name") self~addCheckBox(IDC_CHK_CLASS, , 10, 45, 80, 12, "Class") The bug is in all versions of ooRexx. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:08 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-03-12 20:14 Message: Comitted revision 5692. This is in trunk only. I don't think I'm going to put it in 4.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2969512&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:12:52
|
Bugs item #3171954, was opened at 2011-02-03 12:23 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3171954&group_id=119701 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: ooDialog Group: ooDialog 4.2.0 >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - ComboBox selectIndex() problem Initial Comment: The doc for the selectIndex() method of the ComboBox class does not document what the return actually is, other than saying the return is 0 on error or if the user specified 0. However, the return in those situations is actually -1. Otherwise the return is the index of the newly selected item However, that return is the zero-based Windows index, when the ComboBox class uses 1-based indexes in all cases. That is clearly a bug in my opinion. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:08 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-02-03 16:59 Message: Committed revision 6694. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3171954&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:47
|
Bugs item #2533788, was opened at 2009-01-24 12:59 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2533788&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 >Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog can create wrong object type for controls Initial Comment: This is intended for a post-4.0.0 fix. The way the ooDialog code is structured makes it easy to create the wrong ooDialog class instance for dialog controls. An ooDialog dialog control object is created from the resource ID and what the programmer says the object is. For instance: rb = self~getRadioControl(400) to get a RadioButton object. But, if the 400 ID is actually the ID of say, a list-view control, then we end up with an object that has the methods of a RadioButton object, but actually maps to list-view control. This causes incorrect results for most method invocations on the object, to say the least. ooDialog already has the paradigm of returning .nil for a request to 'get' some type of control when the request is made before the underlying dialog has been created. With the new APIs this can be easily extended to check that the underlying dialog control will actually map to the ooDialog object requested. Return .nil if it doesn't. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 06:54 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:12 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-07-13 17:29 Message: Committed revision 4913. Moved all of the 'getControl' logic of the AdvancedControls class into a native API method. That way, the code has access to the real type of the underlying Window control If the actual type does not match the requested type, then .nil is returned. This is logically the same as the user requesting a control with an invalid resource ID. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2533788&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:46
|
Bugs item #2807760, was opened at 2009-06-17 08:06 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2807760&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 >Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - some event connection methods incorrect Initial Comment: In ooDialog you can connect a Windows event to a method in a ooRexx dialog class. When the Windows event happens, the method in the dialog is invoked. Several of the internal methods related to this are allowing the empty string to be used as the method name. This of course doesn't work. In addition, in the doc the railroad track diagram for some of the methods indicates that the method name is optional, although the text itself doesn't indicate that. The method name can not be optional. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:15 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-07-03 18:35 Message: Committed revision 4872. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-06-17 09:24 Message: Rick, As far as the empty string goes for a method name, the C code that implements the invocation of the ooRexx method, would just generate an error. You'd end up with something similar to: interpret '(234459, 89223)' the way the code is. So, all in all, I think this was just a mistake in implementation, not something intentional. Although, I'm glad you reminded me that "" is a valid method name, hopefully it will sink in. Because it seems to me you reminded me of that in the past. <grin> ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-06-17 08:38 Message: Hmmm, ... well thanks Rick. You're right in assuming I had not considered that. I don't think this was the intent here, because in the implementing C code they checked for the empty string and rejected it. Returned an error code and did not connect the event to a method a name of "". The original code: if (!prog.strlength) return 0; In the couple of methods where the doc seems to indicate that the method name argument is optional, the code does not check that it is ommitted, it just uses the argument name. So in those cases, the method invoked would be the argument name. Which in one case would be msgToRise and in another case msgToRaise. Since this isn't documented, it would take a pretty savy user to understand what method they are suppossed to implement. And, there is a related bug, which I didn't spell out - trying not to be too wordy. When a dialog template is created from parsing a .rc script file, the user can specify to automatically connect buttons to a method. Using the CONNECTBUTTONS option. The code essentially goes: if connectbuttons then self~connectButton(id, methodname) else self~connectButton(id) I just don't think that is intentional, because the else statement would just return an error code. I'll put some more thought into what changes I make. <grin> ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-06-17 08:08 Message: I'm not sure I understand all of the specifics here, but a "" string IS a valid ooRexx method name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2807760&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:43
|
Bugs item #2844058, was opened at 2009-08-24 23:01 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2844058&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Berg (martinberg) Assigned to: Mark Miesfeld (miesfeld) Summary: Menu is not created if text on entry has more than 47 chars Initial Comment: The menu is not created if one text has more than 47 characters. The following code works fine, but if 47 is changed to 48 ore any higher value the menu is not created. self~CreateMenu(); self~AddPopupMenu('Test') self~AddMenuItem('Test1',221,,'TEST'); self~AddMenuItem('Test1'~Left(47,'*'),221,,'TEST'); self~AddMenuItem('Test2',222,'END','TEST'); self~AddMenuSeparator() self~AddMenuItem('TestX',223,'END','TEST'); ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:06 Message: This fix will be in the next major release of ooDialog, but not in the 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-23 16:59 Message: Committed revision 5619. For the 4.0.1 bug release, I eased up the restriction on the length of the menu item text to 64 characters. But the restriction on the length is still there. The real fix will have to be in the next release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-08-26 08:04 Message: The menu templates are created in memory, and in 3.2.0 I had people report to me that ooRexx crashed. This was due to them creating an in-memory template larger than allocated memory. For each menu item, the bulk of the memory used is for the text of the item, which is double-byte. To prevent the crashes I limit the amount of text for the menu item to 47 characters. This seemed more than enough. I looked at all the menus on my system and could not find any even close to 30 characters. This is fixed in trunk, where the new APIs made it easy to create a more robust Menu class. If the user attempts to add a menu item that would extend past allocated memory, a condition is raised. There has always been an option to specify a larger number of menu items than the default, so if the user hits that condition, they can specify that their menu needs more room. The restriction on the length of the text is lifted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2844058&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:42
|
Bugs item #2855771, was opened at 2009-09-09 21:32 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2855771&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 >Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: The StaticControl~setIcon() method may crash Initial Comment: There is a bug in the .Image class in ooDialog that will cause a crash if wrong arguments are supplied when creating a new Icon image. This could show up for instance in a method like setIcon of the static control A work around would be to not use wrong arguments when creating an icon image. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:18 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 09:03 Message: This is fixed in trunk since revision 5162. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-02-25 17:54 Message: The fix for this will need to be deferred, it is too intertwined with other ooDialog changes. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-09 21:44 Message: Committed revision 5162. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2855771&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:38
|
Bugs item #2869326, was opened at 2009-09-28 16:55 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869326&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 >Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooticket.rex sample has bug setting days Initial Comment: In the ooticke.rex sample, an ooDialog sample, the dialog is supposed to set the radio button in the 'Days' radio button to the current day. This only works if the current day is Sunday. In a CategoryDialog, which this example is, all dialog controls on all of the pages have to have an unique ID. If they do not, the "setData" / "getData" methods are not guarenteed to work. The sample uses the same resource IDs for the radio buttons on the 'Days' page as it does for some of the controls on the 'Movies' page, which causes this bug. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-28 16:56 Message: Committed revision 5219. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869326&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-03 15:11:37
|
Bugs item #2869333, was opened at 2009-09-28 17:04 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869333&group_id=119701 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: ooDialog >Group: ooDialog 4.2.0 >Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: ooDialog - build.rex out of date Initial Comment: The distribution includes a file build.rex and places it in samples\oodialog\source. This file is way out of date and should either be brought up to date, or removed from the distribution. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-02-03 07:09 Message: This fix will appear in the next major release of ooDialog, it will not be included in an ooRexx bug fix release ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-09-08 08:25 Message: This fix will be in the next major release of ooDialog, but not in the ooRexx 4.1.0 release. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-10 16:19 Message: Committed revision 6094. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2869333&group_id=119701 |