You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(35) |
Jun
(131) |
Jul
(73) |
Aug
(40) |
Sep
(65) |
Oct
(157) |
Nov
(116) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(12) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(5) |
Jul
(26) |
Aug
(81) |
Sep
(49) |
Oct
(48) |
Nov
(3) |
Dec
(5) |
2009 |
Jan
(4) |
Feb
(22) |
Mar
(17) |
Apr
(13) |
May
(4) |
Jun
(11) |
Jul
(17) |
Aug
(20) |
Sep
(38) |
Oct
(5) |
Nov
(4) |
Dec
|
2010 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(7) |
Jun
(4) |
Jul
(1) |
Aug
(10) |
Sep
(73) |
Oct
(26) |
Nov
(2) |
Dec
(25) |
2011 |
Jan
(23) |
Feb
(39) |
Mar
(12) |
Apr
(5) |
May
(3) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(16) |
Nov
(2) |
Dec
|
2012 |
Jan
(5) |
Feb
(5) |
Mar
(13) |
Apr
|
May
(3) |
Jun
(23) |
Jul
(10) |
Aug
(29) |
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2012-08-13 09:39:34
|
Feature Requests item #3315584, was opened at 2011-06-12 18:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3315584&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: LesK (vmrexx) Assigned to: Nobody/Anonymous (nobody) Summary: Add VAR option to EXECIO Initial Comment: Justification: Completeness. It is counter-intuitive to the mainframe programmer to use STEM and not supply the period on the stemname in order for ooRexx to recognize a varname. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-13 02:39 Message: j5vBEf <a href="http://vfmgjnutfgda.com/">vfmgjnutfgda</a>, [url=http://tafbzvruoijp.com/]tafbzvruoijp[/url], [link=http://wnxrvxkndgmm.com/]wnxrvxkndgmm[/link], http://wqilawlmzvjv.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3315584&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 15:48:54
|
Feature Requests item #3555126, was opened at 2012-08-07 08:48 Message generated for change (Tracker Item Submitted) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3555126&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: APIs Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Nobody/Anonymous (nobody) Summary: Add positive whole number type to APIs. Initial Comment: For many ooRexx built-in functions and methods, the numeric values fall into the categories "whole number", "non-negative whole number", and "positive whole number". In the API signatures, the first maps to wholenumber_t, the second maps to "stringsize_t", but there is no equivalent to "positive whole number". To achieve this, one would have to request a stringsize_t value and apply an additional range check to exclude zero. It would be nice if the API interface could handle this directly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3555126&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 15:42:05
|
Feature Requests item #3555125, was opened at 2012-08-07 08:42 Message generated for change (Tracker Item Submitted) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3555125&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Nobody/Anonymous (nobody) Summary: Add mutableBuffer support to stream class. Initial Comment: For some applications, it is more efficient to use mutable buffers for handling input and output. Unfortunately, since the stream class only supports strings, it is necessary to create short-lived string objects when transferring data to or from the mutable buffer. The stream class should be able to do this directly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3555125&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:23:18
|
Feature Requests item #2010144, was opened at 2008-07-03 16:01 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010144&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: Add the Date and Time Picker control Initial Comment: ooDialog has not been updated with any new controls for some time. It would be nice to add the Date and Time Picker control. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:14 Message: A basic DateTimePicke control class is implemented in trunk. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-02-05 09:31 Message: I'd like to add an additional requirement for support for DateTime objects. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:29 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-07-03 19:18 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2643. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010144&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:23:17
|
Feature Requests item #2010145, was opened at 2008-07-03 16:02 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010145&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: Add the Month Calendar control Initial Comment: It would be nice to add the Month Calendar control to ooDialog. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:13 Message: A basic, workable MonthCalendar control class is implemented in trunk. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-04-12 22:23 Message: Committed revision 4359. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-04-12 22:22 Message: Committed revision 4359. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:29 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-07-03 19:17 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2643. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010145&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:23:12
|
Feature Requests item #2041165, was opened at 2008-08-06 21:19 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2041165&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: Make menus class objects in ooDialog Initial Comment: Used to track changes to ooDialog. Menus are far more flexible than originally designed in ooDialog. They should be represented as a class and subclasses rather than coupled so tightly with the dialog class. In addtion the Menu classes should be enhanced to expose more of the menu functionality to the ooDialog programmer. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:12 Message: This is implemented in trunk. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:28 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-08-06 21:36 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2873. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2041165&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:23:06
|
Feature Requests item #2842707, was opened at 2009-08-22 12:02 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2842707&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: Fix and document return from DynamicDialog::create() Initial Comment: Currently the return from DynamicDialog::create() is not documented anywhere, except indirectly by this example: rc = MyDialog~Create(20, 20, 300, 200, "My first Dialog", , "THICKFRAME NOMENU", , "Courier", 12, 100) if rc <> 0 then MyDialog~Execute Which implies that 0 is failure, not 0 is success. Currently the code returns the pointer value of the in-memory dialog template. This is somewhat silly, because the user can not possibly do anything with the pointer value, and the ooDialog code does not use it either. Internally ooDialog uses the activePtr attribute. The return should be .true for success and .false for failure, and documented that way. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-08-22 12:25 Message: Committed revision 5096. Code Committed revision 5097. Documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2842707&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:23:05
|
Feature Requests item #2871040, was opened at 2009-09-30 15:32 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2871040&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 - remove distinction between old and 'new' controls Initial Comment: The distinction between the old controls and the 'new' controls in ooDialog is an artificial that should be removed. By putting some control methods in a separate AdvancedControls class, the user is currently forced to inherit that class in their subclasses. All of the methods in the AvancedControl class really belonged in already existing classes. If the methods were moved to some already existing classes, where they belong, there would be no need to inherit AdvancedControls. You could just inherit the type of dialog you are creating, UserDialog, ResDialog, CategoryDialog, etc.. AdvancedControls would be left as a deprecated empty class. All existing dialogs that inherit AdvancedControls would just work the same, so there are no backwards compatibility issues. There are / were 3 basic types of methods in AdvancedControls: 1.) Methods to place a control in the in-memory dialog template. These belonged in the existing DynamicDialog class that already had the methods for working with the in-memory dialog template. These methods would be moved to DynamicDialog. 2.) Methods to create an attribute in the dialog object to represent a control and connect the control with the attribute. Methods to do that for check boxes, radio buttons, edit controls, list boxes, combo boxes, and more, already existed in PlainBaseDialog. So the methods to do the same thing for the 4 'new' controls, List-view, tree-view, track bar, and tab should have been placed alongside the existing methods. These 4 methods in AdvancedControls would be moved to PlainBaseDialog. 3.) Methods to get a new control object. Those methods, I think, really should have just been placed in BaseDialog. All non-trivial dialogs are subclasses of BaseDialog. These methods would be moved to BaseDialog. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2871040&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:22:59
|
Feature Requests item #3168768, was opened at 2011-01-31 08:18 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3168768&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 - improve connectKeyPress methods Initial Comment: In ooDialog the connectKeyPress(), and related methods, allow the connecting of key combination like Ctrl-S or Alt-Home to a method in the Rexx dialog. This works fine for key events where the user is physically typing the keys. However, it is not uncommon for users to have "remote control" applications that insert key strokes into the message queue of windows running in a different process. The connectKeyPress methods will, currently, not detect this for key combinations because the methods check if the modifier keys (Ctrl, Alt, and Shift) are physically down. It would be nice to also detect the key event when the key combination is inserted into the message queue by an outside process. This can be done by using a different Windows API. The Rexx programmer could have an option to specify the behavior. By default the connectKeyPress() methods would behave as now, a match for the key event would check that modifier key(s) were physically depressed. By adding the VIRT keyword to the key filter, the programmer could specify to detect inserted key events also. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-31 19:33 Message: Committed revision r6675. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3168768&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:22:58
|
Feature Requests item #3196741, was opened at 2011-03-01 17:08 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3196741&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 message, color, etc tables should be dynamic Initial Comment: ooDialog uses a number of tables to keep track of things. Message tables, color tables, bitmap tables, etc. Those tables have always been, a rather large, fixed size. No matter how big the table, there are a few people who want / need a bigger table. Rather than allocated hugh fixed size tables, it would be better to allocate smaller tables, sufficient for the average dialog, and expand the table size if / when needed for the unusual dialog. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-03-01 20:10 Message: Committed revision 6818. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3196741&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:22:55
|
Feature Requests item #3427258, was opened at 2011-10-22 10:16 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3427258&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: Accepted Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Mark Miesfeld (miesfeld) Summary: The MonthCalendar control needs a setStyle() method Initial Comment: When a date and time picker control has a child month calendar, it is common for the programmer to set some specific styles for the month calendar. The date and time picker control has a DateTime_SetMonthCalStyle() function to allow the programmer to do this. However, that funtion is for Vista or later only. For XP or Windows 2000, it is easy enough for the programmer to change the style, in C or C++. For the Rexx programmer a native method needs to be added to the MonthCalendar object to do this. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-10-23 08:44 Message: Committed revision 7242. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3427258&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:21:39
|
Feature Requests item #1651215, was opened at 2007-02-03 06:01 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1651215&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: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Rick McGuire (bigrixx) Summary: Add a method that will return string subwords as an array. Initial Comment: It would be very handy if the string class supported a method that would return an array of word tokens. This would ideally be like the subword class, but return an array rather than a string. This would be particularly handy when combined with DO OVER do word over string~wordlist say word end ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2012-08-07 07:21 Message: Mass updated this one by mistake. Put it back where it was. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2011-02-03 05:40 Message: final Committed revision 6692. This has been added as the subWords method. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-19 11:26 Message: Yeah, you're right. I thought of multiple spaces too late. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2011-01-19 10:52 Message: And I'm going to reopen it because this has NOT been implemented. makearray(" ") is not semantically equivalent to what I've requested here. In particular, it does not apply the same semantics as subword with respect to multiple blanks between the word tokens. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-19 10:47 Message: I'm going to close this RFE because at some point it was implemented: str = 'Now is the time for all good men to come to the aid of their country.' do i over str~makeArray(" ") say i end works in .4.1.0. ---------------------------------------------------------------------- Comment By: Jon Wolfers (sahananda) Date: 2008-10-18 22:42 Message: Is this functionality not already available? ........................................... rexxtry.rex on WindowsNT s = 'The cat sat on the mat' ........................................... rexxtry.rex on WindowsNT do w over s~makearray(' ') ; say w ; end The cat sat on the mat ........................................... rexxtry.rex on WindowsNT thanks, Jon ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2007-03-17 10:30 Message: Logged In: YES user_id=662126 Originator: NO What would be the characters delimiting words? Just blanks, or also other whitespace? What about punctuation characters? What constitutes a word? Just the letters, a combination of letters and digits? How about non-US-characters which are part of words? Ideally, this method should truly be able to deal with words of all kind correctly. (But I thought that would become possible only with Unicode and the test-functions going with it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1651215&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:38
|
Feature Requests item #1118078, was opened at 2005-02-07 11:16 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1118078&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: Accepted Priority: 5 Private: No Submitted By: Jon Wolfers (sahananda) Assigned to: Mark Miesfeld (miesfeld) Summary: OODialog VirtualKeyCodes Class Alt-Ctrl-Shift Key Combinatio Initial Comment: At the moment, the Virtual Key Code Class does not distinguish pressing a single key or pressing a key in combination with ALT (or MENU as it is called), CTRL or SHIFT. At least this is certainly the case when it is used in conjunction with the KEYDOWN event of the ConnectListNotify Method of the MessageExtensions class. It would be INVALUABLE to be able to distinguish these key combinations. At present you get a notification of the pressing of the (for example) MENU key and then a notification of the key pressed in combination with it. I suppose for backwards compatibility one would need an optional parameter to request these key combinations. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2012-01-20 18:44 Message: Committed revision 7443. I added a keyword notification, KEYDOWNEX (Key down extended) that sends as arguments to the event handler all the information known at the time the notification is sent by the list view. This does not change the Virtual Key Code class, there is no such thing as a virtual ctrl-C or alt-F key code. Rather when the notification arguments are sent to the Rexx method they include arguments that tell whether the Ctrl, Alt, Shift key are down. So, if the user presses, say Alt-F, you will still see a notifcation when the user presses Alt, (MENU key,) and then a different notification for F, that's the way Windows works. But, when you get the F notification you will have an argument that specifies that the Alt key is down. By the way, ooDialog 4.2.0 includes the .VK class as a replacement for the Virtual Key Code class. The .VK class includes every single virtual key in Windows, rather than just some of them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1118078&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:31
|
Feature Requests item #1503164, was opened at 2006-06-08 14:08 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1503164&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: Jon Wolfers (sahananda) Assigned to: Mark Miesfeld (miesfeld) Summary: OODialog Context Menu class Initial Comment: I dont know if this is possible, but one thing it is hard to build with ooDialog is a context menu, ie: right click on a control and get a frameless floating menu at the mouse point and the ability to launch methods by clicking it. If I was designing it, I would require use of a connect method to assign it to a control and pass a two dimensional array of menu texts, methods to connect, parameters,and options. Something along the lines of: contextArr=.array~new(2,4) contextArr[1,1]='&Quit' contextArr[1,2]='OK' contextArr[1,4]='Divider' contextArr[2,1]='S&ave' contextArr[2,2]='SaveFile' contextArr[2,3]=filename contextArr[2,4]='Grayed' self~ConnectContextMenu2Control(12,contextArr) If the mouse right button was clicked over control 12 then a menu would appear at the mouse point with two options Quit & Save. Left clicking Quit (or pressing Q) would start the OK method. Left clicking Save (or pressing a) would run the savefile method, passing filename as an argument. clicking elsewhere would do nothing (as would pressing escape) The arrow keys could also be used to move the selection and the enter key to select it. A second parameter would be passed to called methods giving the title of the control or control element the mouse was over. Is this anywhere near possible? ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:17 Message: A very full-featured context menu class is added to ooDialog and implemented in trunk. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:30 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Jon Wolfers (sahananda) Date: 2008-08-06 22:19 Message: Logged In: YES user_id=667060 Originator: YES Thanks Mark, It looks great. I think your approach is correct - at the time I submitted the RFE I didn't know it was possible. Jon ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-08-06 21:35 Message: Logged In: YES user_id=191588 Originator: NO Committed revision 2873. Jon, I've turned menus into classes in ooDialog and exposed most of the Windows menu functionality to the ooDialog programmer. One of the subclasses is .PopupMenu which represents the Context menu. The ooDialog programmer interacts with menu objects in ways similar to how she interacts with dialog or dialog control objects. The menus objects create the underlying Windows menu objects, which then behave as the OS dictates. The functionality of the Windows menu objects is exposed by methods of the ooDialog menu objects. I think you will be please with the results, although it is not as you proposed. I didn't design a context menu, instead I used what Windows already supplies. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-06-14 13:42 Message: Logged In: YES user_id=191588 Originator: NO I'm going to assign this to myself, it's something I'm planning on getting to. I'd prefer that Rick spent his time on the core interpreter. <grin> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1503164&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:26
|
Feature Requests item #1651215, was opened at 2007-02-03 06:01 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1651215&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: ooDialog 4.2.0 Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Rick McGuire (bigrixx) Summary: Add a method that will return string subwords as an array. Initial Comment: It would be very handy if the string class supported a method that would return an array of word tokens. This would ideally be like the subword class, but return an array rather than a string. This would be particularly handy when combined with DO OVER do word over string~wordlist say word end ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2011-02-03 05:40 Message: final Committed revision 6692. This has been added as the subWords method. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-19 11:26 Message: Yeah, you're right. I thought of multiple spaces too late. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2011-01-19 10:52 Message: And I'm going to reopen it because this has NOT been implemented. makearray(" ") is not semantically equivalent to what I've requested here. In particular, it does not apply the same semantics as subword with respect to multiple blanks between the word tokens. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-19 10:47 Message: I'm going to close this RFE because at some point it was implemented: str = 'Now is the time for all good men to come to the aid of their country.' do i over str~makeArray(" ") say i end works in .4.1.0. ---------------------------------------------------------------------- Comment By: Jon Wolfers (sahananda) Date: 2008-10-18 22:42 Message: Is this functionality not already available? ........................................... rexxtry.rex on WindowsNT s = 'The cat sat on the mat' ........................................... rexxtry.rex on WindowsNT do w over s~makearray(' ') ; say w ; end The cat sat on the mat ........................................... rexxtry.rex on WindowsNT thanks, Jon ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2007-03-17 10:30 Message: Logged In: YES user_id=662126 Originator: NO What would be the characters delimiting words? Just blanks, or also other whitespace? What about punctuation characters? What constitutes a word? Just the letters, a combination of letters and digits? How about non-US-characters which are part of words? Ideally, this method should truly be able to deal with words of all kind correctly. (But I thought that would become possible only with Unicode and the test-functions going with it?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1651215&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:20
|
Feature Requests item #2010144, was opened at 2008-07-03 16:01 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010144&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: Add the Date and Time Picker control Initial Comment: ooDialog has not been updated with any new controls for some time. It would be nice to add the Date and Time Picker control. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:14 Message: A basic DateTimePicke control class is implemented in trunk. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2009-02-05 09:31 Message: I'd like to add an additional requirement for support for DateTime objects. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:29 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-07-03 19:18 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2643. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010144&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:15
|
Feature Requests item #2010145, was opened at 2008-07-03 16:02 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010145&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: Add the Month Calendar control Initial Comment: It would be nice to add the Month Calendar control to ooDialog. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:13 Message: A basic, workable MonthCalendar control class is implemented in trunk. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-04-12 22:23 Message: Committed revision 4359. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-04-12 22:22 Message: Committed revision 4359. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:29 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-07-03 19:17 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2643. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2010145&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:10
|
Feature Requests item #2041165, was opened at 2008-08-06 21:19 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2041165&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: Make menus class objects in ooDialog Initial Comment: Used to track changes to ooDialog. Menus are far more flexible than originally designed in ooDialog. They should be represented as a class and subclasses rather than coupled so tightly with the dialog class. In addtion the Menu classes should be enhanced to expose more of the menu functionality to the ooDialog programmer. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:12 Message: This is implemented in trunk. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-02-05 09:28 Message: Postpone this feature until after 4.0.0 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-08-06 21:36 Message: Logged In: YES user_id=191588 Originator: YES Committed revision 2873. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2041165&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:09
|
Feature Requests item #2722261, was opened at 2009-03-30 10:41 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2722261&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: Georg Alm (almgeor) Assigned to: Mark Miesfeld (miesfeld) Summary: FileNameDialog Initial Comment: Rezisable function window? ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-01 22:08 Message: This was an easy one to implement. Committed revision 5134. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2722261&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:04
|
Feature Requests item #2842707, was opened at 2009-08-22 12:02 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2842707&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: Fix and document return from DynamicDialog::create() Initial Comment: Currently the return from DynamicDialog::create() is not documented anywhere, except indirectly by this example: rc = MyDialog~Create(20, 20, 300, 200, "My first Dialog", , "THICKFRAME NOMENU", , "Courier", 12, 100) if rc <> 0 then MyDialog~Execute Which implies that 0 is failure, not 0 is success. Currently the code returns the pointer value of the in-memory dialog template. This is somewhat silly, because the user can not possibly do anything with the pointer value, and the ooDialog code does not use it either. Internally ooDialog uses the activePtr attribute. The return should be .true for success and .false for failure, and documented that way. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-08-22 12:25 Message: Committed revision 5096. Code Committed revision 5097. Documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2842707&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:19:00
|
Feature Requests item #2869118, was opened at 2009-09-28 12:09 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2869118&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 should only need to ::require 1 file Initial Comment: The original ooDialog implementation tried to save system resources by breaking up the ooDialog implementation code into 3 separate files. Which files to require has always been confusing to some users, and the rationale behind breaking the implementation into 3 files is no longer valid. Prior to ooRexx 4.0.0, each separate file only registered a subset of the external functions ooDialog uses. With ooRexx 4.0.0 and its improved package loading all the function entry points are registered no matter which of the 3 separate files is required. It would be easier and more convenient if there were only 1 package file required for any ooDialog program. One pretty obvious choice for the file name is ooDialog.cls. Although, ooDialog.frm might also make sense since the ooDialog package is not a single class but rather a framework to support developing GUI Rexx programs on Windows. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2009-09-28 17:09 Message: Committed revision 5220. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2869118&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:18:56
|
Feature Requests item #2871040, was opened at 2009-09-30 15:32 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2871040&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 - remove distinction between old and 'new' controls Initial Comment: The distinction between the old controls and the 'new' controls in ooDialog is an artificial that should be removed. By putting some control methods in a separate AdvancedControls class, the user is currently forced to inherit that class in their subclasses. All of the methods in the AvancedControl class really belonged in already existing classes. If the methods were moved to some already existing classes, where they belong, there would be no need to inherit AdvancedControls. You could just inherit the type of dialog you are creating, UserDialog, ResDialog, CategoryDialog, etc.. AdvancedControls would be left as a deprecated empty class. All existing dialogs that inherit AdvancedControls would just work the same, so there are no backwards compatibility issues. There are / were 3 basic types of methods in AdvancedControls: 1.) Methods to place a control in the in-memory dialog template. These belonged in the existing DynamicDialog class that already had the methods for working with the in-memory dialog template. These methods would be moved to DynamicDialog. 2.) Methods to create an attribute in the dialog object to represent a control and connect the control with the attribute. Methods to do that for check boxes, radio buttons, edit controls, list boxes, combo boxes, and more, already existed in PlainBaseDialog. So the methods to do the same thing for the 4 'new' controls, List-view, tree-view, track bar, and tab should have been placed alongside the existing methods. These 4 methods in AdvancedControls would be moved to PlainBaseDialog. 3.) Methods to get a new control object. Those methods, I think, really should have just been placed in BaseDialog. All non-trivial dialogs are subclasses of BaseDialog. These methods would be moved to BaseDialog. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=2871040&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:18:52
|
Feature Requests item #3143088, was opened at 2010-12-23 10:59 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3143088&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: hex (hexit34) Assigned to: Mark Miesfeld (miesfeld) Summary: Add test for MENUEX in oodialog.cls Initial Comment: Using resource editors which creates .rc files with MENUEX in menu resources doesn't work There is a comment in OODIALOG.CLS -- TODO we could parse extended menus by looking for MENU *and* MENUEX So a test for MENUEX is appreciated. Replacing the above comment with: select when s~wordpos("MENU ") > 0 then n = s~wordpos("MENU ") when s~wordpos("MENUEX ") > 0 then n = s~wordpos("MENUEX ") --n = s~wordpos("MENUEX") -- TODO we could parse extended menus by looking for MENU *and* MENUEX otherwise nop end will solve the problem TIA ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-12-30 08:43 Message: I tried resedit on Windows 7 where I have the latest SDK. Also tried graying some of the menu items. Still no luck. I'm going to close this RFE now, the next ooDialog build will handle either MENU or MENUEX in .rc resource script files. ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-29 23:34 Message: About resedit producing MENUEX, I think it happens when you in the editor /rc file set a menuitem to GRAYED for example, But it seems that it's dependent on the SDK used and/or OS. At home using win7 and SDK7 it produces menuex (GRAYED is set to MFS_GRAYED for menuitem in rc file) . At work using WinXP and sdk win2003 server, RESEDIT does NOT produce MENUEX (GRAYED is just GRAYED for an menuitem in the rc file). Maybe that also explains why I at work can't open an rc file with a menuex statement i resedit. Or shorter, I have no idea how/when it happens :-) ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-12-29 21:34 Message: The current code to parse a MENU resource does not parse a MENUEX resource correctly, in that it does not recognize any of the extended features for menus. However, it does generate an in-memory MENU template from the MENUEX resource. I reworked the code so that it will accept either a MENU or a MENUEX resource in a .rc script file. On a side note, mye ResEdit is also 1.5.4 and it only produces MENU resources, will not produce MENUEX resources. I'd be interested in knowing if you have to do or set anythign special to get it to produce the MENUEX resource? ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-24 13:01 Message: Well this is a sample .rc dialog with MENUEX // Generated by ResEdit 1.5.4 // Copyright (C) 2006-2010 // http://www.resedit.net #include <windows.h> #include <commctrl.h> #include <richedit.h> #include <winuser.h> #include "errDialog.h" // // Menu resources // IDR_MENU1 MENUEX BEGIN POPUP "File", 0, 0, 0 BEGIN MENUITEM "&New", IDM_FILE_NEW, 0, MFS_GRAYED MENUITEM "&Open", IDM_FILE_OPEN, 0, 0 MENUITEM "&Save", IDM_FILE_SAVE, 0, MFS_GRAYED MENUITEM "Save as...", IDM_FILE_SAVEAS, 0, MFS_GRAYED MENUITEM "", 0, MFT_SEPARATOR, 0 MENUITEM "Exit", IDM_EXIT1, 0, 0 END POPUP "Edit", 0, 0, 0 BEGIN MENUITEM "&Copy Ctrl+C", IDM_EDIT_COPY, 0, 0 MENUITEM "Paste Ctrl+V", IDM_EDIT_PASTE, 0, 0 END POPUP "Help", 0, 0, 0 BEGIN MENUITEM "Help F1", IDM_HELP, 0, 0 MENUITEM "About", IDM_ABOUT, 0, 0 END END // // Dialog resources // IDD_DIALOG1 DIALOGEX 0, 0, 580, 233 STYLE DS_3DLOOK | DS_CENTER | DS_MODALFRAME | DS_SHELLFONT | WS_CAPTION | WS_VISIBLE | WS_POPUP | WS_SYSMENU CAPTION "Dialog" MENU IDR_MENU1 FONT 8, "Ms Shell Dlg", 400, 0, 1 BEGIN DEFPUSHBUTTON "OK", IDOK, 457, 202, 50, 14, 0, WS_EX_TRANSPARENT PUSHBUTTON "Cancel", IDCANCEL, 517, 202, 50, 14 CONTROL "", IDC_LIST1, WC_LISTVIEW, WS_TABSTOP | WS_BORDER | LVS_ALIGNLEFT | LVS_NOLABELWRAP | LVS_NOSORTHEADER | LVS_SINGLESEL | LVS_REPORT, 167, 23, 400, 110, WS_EX_CLIENTEDGE | WS_EX_RIGHT PUSHBUTTON "Delete", IDC_Delete, 172, 143, 26, 14 END // // Icon resources // IDI_ICON1 ICON ".\\App.ico" ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-12-24 07:27 Message: I also use ResEdit, and recommend it to others. Unfortunately, I can not get it to produce extended menus. MENU is the old style menu resource, while MENUEX is the extended menu resource. There are not a lot of differences, but one difference is that MENUEX allows assigning an ID to separators. Having an ID assigned to a separator allows you to remove them by ID rather than position. This is very convenient in multi-level menus. Anyhow, could you attach the .rc file that has the MENUEX in it to this tracker item. I'd like to take a look at it. ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-23 15:19 Message: And once you change the .rc script file from MENUEX to MENU it's not possible to open the .rc file in resedit again without changing back to MENUEX in .rc script again, Most annoying part I asume. Now here (Sweden) it's Christmas eve so Merry Christmas to you all ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-23 14:36 Message: I use resedit http://www.resedit.net/ 64bit, but I don't actually know the difference between MENU and MENUEX, I just realize that resedit always create MENUEX but I change in the .rc file to MENU to be able to run oorexx oodialog programs on an unmodified OODIALOG.CLS member and have never seen any problems with that change, so far. Resedit is also able to produce .res and .dll files but I have never got it to work with oodialog, maybe my knowledge is to limited in this matter. My learning is raising in the creation of oodialogs and I like the the new oodialog 4.2. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-12-23 11:11 Message: Thanks for this too. As you saw, it is on my TODO list. The problem I had was I couldn't find a resource editor, (at the time,) that produced extended menus to test with. What resource editor are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3143088&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:18:51
|
Feature Requests item #3147607, was opened at 2010-12-29 06:50 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3147607&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: hex (hexit34) Assigned to: Mark Miesfeld (miesfeld) Summary: oodialog 4.2 GroupBox caption alignment Initial Comment: Using a resource script for dialog and creating a GroupBox with caption it's possible to align the caption text of the groupbox with BS_LEFT. works also in oodialog 4.2 But it's also possible to use BS_CENTER and BS_RIGHT but these keywords in rc file is not recognized by oodialog 4.2 GROUPBOX "Text", IDC_STATIC, 9, 170, 167, 30, BS_RIGHT GROUPBOX "Status", IDC_STATIC, 9, 170, 167, 30, BS_CENTER Could these 2 keywords for GroupBox also be added to oodialog ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-12-29 15:37 Message: Committed revision 6530. As you noticed, I had already added the code for the BS_RIGHT style. I believe from some comments I had in the code that I could not get BS_CENTER to paint correctly. However I got that working, so BS_CENTER is now supported. That the text *should* be on the left comes from Microsoft's guidelines. I'll leave it up to the programmer if he wants to follow the guidelines or not. I wanted the GroupBox class in ooDialog to support all the styles available. BS_LEFT, BS_CENTER, and BS_RIGHT are the only 3 styles that have an effect for group boxes. ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-29 07:16 Message: Well after some reading I understand that this request should be marked as invalid. According to Microsoft the text should always be in upper left corner of the box ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2010-12-29 06:55 Message: Actually it's only BS_CENTER that is missing and not working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3147607&group_id=119701 |
From: SourceForge.net <no...@so...> - 2012-08-07 14:18:46
|
Feature Requests item #3157503, was opened at 2011-01-13 10:25 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3157503&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: hex (hexit34) Assigned to: Mark Miesfeld (miesfeld) Summary: oodialog 4.2 editcontrol setcue Initial Comment: Using rc file created with ResEdit 1.5.4 and an edit control like this (ES_UPPERCASE) EDITTEXT IDC_USERID, 20, 172, 66, 12, ES_AUTOHSCROLL | ES_UPPERCASE and then in the dialog use method setcue("Enter Userid") on this editcontrol the setcue text will also be displayed in uppercase Is it possible to get the setcue text as defined and still display user input in the editcontrol in uppercase ? I.e I want to display entered input in uppercase but setcue text in mixed case. Open Object Rexx Version 4.2.0 Build date: Jan 12 2011 Addressing Mode: 64 Win 7 ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2011-01-13 22:43 Message: You are correct about the behaviour of setcue, in xp it works, but not in WIN7 (at least not for me) ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-13 17:33 Message: 1.) I do not see the behavior you describe concerning the setting of the cue in a ES_UPPERCASE edit control. I'm attaching a sample program that works fine for me. It uses a .rc file created by resEdit. The IDC_EDIT_STATE edit control has the upper case style. When I set the cue to 'state', 'state' is what I see. Not 'STATE' The program also has a number only edit control and I can set the cue there to Zip and Zip is what shows. Now, this is on XP. It may be that the behavior is different on Windows 7. If so, then there is nothing that ooDialog can do about it. 2.) Your point about the focus is good. There is a now a second parameter in the underlying Windows API that controls if the cue disappears when the edit control gets the focus or if it disappears when the user first types a character. That parameter was not present when I first wrote the setCue method. I've added a second optional parameter to the setCue method to use this. When set to .true, the cue text will not disappear until the user types a character. When set to .false, the default, the text will disappear when the edit control gets the focus. Unfortunately this does not work on XP, but I bet it works on Vista or later. I will test this on Windows 7 tonight, or as soon as I get a chance. Thanks for bringing this up. ---------------------------------------------------------------------- Comment By: hex (hexit34) Date: 2011-01-13 13:09 Message: Comparing with the login in win7, even if the focus is on the password field the setcue text is showing until you types something in. In ooDialog the setcue text disappears as soon as the editcontrol get the focus, it would be good if the text is shown until something is typed in the field, this will not of course solve the problem with upper/lower case. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-01-13 11:05 Message: Off of the top of my head I don't think this is possible. If you are using exactly "Enter Userid" for you argument to the setCue() method, then the underlying edit control is what is changing the text, not the ooDialog framework. There is probably no way to change this. At least I don't see any way. You might be able to do something like this: Remove the ES_UPPERCASE from the .rc definition. connect the GOTFOCUS and LOSTFOCUS edit control events to methods in you dialog. set your cue in initdialog In you event handler for the GOTFOCUS event handler add the UPPERCASE style to the edit control. In your LOSTFOCUS event handler remove the UPPERCASE style again. This might work if you play with it a little, but I can't be sure. I'll do a little more research and see if there is some other approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684733&aid=3157503&group_id=119701 |