Announcement: IR V4.0.3 Beta

Mark Pierson · Post by **Mark Pierson** » Tue Mar 16, 2004 7:48 am

e34m5 wrote:I would need to create a separate dialog to display the notes but that is not a big deal. I will defer to the majority on this one.

The whole point is to easily see the note, so I don't think the user should need to open a secondary dialog to view them. Perhaps a Notes column can be added to the display grid?

e34m5 · Post by **e34m5** » Tue Mar 16, 2004 7:50 am

Thought of that as well...however that requires the whole grid tab size to be increased and that affects more than just the keymoves tab.

How about if for now we leave as is and later look at a modification....

Juppers · Post by **Juppers** » Tue Mar 16, 2004 8:21 am

For my vote, put me down for the tooltip idea. That would just be nifty and not take up any additional space.

e34m5 · Post by **e34m5** » Tue Mar 16, 2004 8:23 am

That would be tooltip plus separate screen to display notes correct

johann83 · Post by **johann83** » Tue Mar 16, 2004 9:34 am

Mark Pierson wrote:The whole point is to easily see the note, so I don't think the user should need to open a secondary dialog to view them. Perhaps a Notes column can be added to the display grid?

This is also what I originally envisioned when we started talking about improvements to IR. Requiring the user to open a second window is almost useless in my opinion, while a tooltip is also less than ideal.

The problem with a tooltip is, as was mentioned, some users don't know they are there. Also, you can't edit from within a tooltip. But, since I'm not a Delphi coder, I'd be happy with a tooltip for now.

Matt

e34m5 · Post by **e34m5** » Wed Mar 17, 2004 12:02 pm

Latest version is now available with:

- Notes display on the grid for both keymoves and macros
- PopMenu in keymove grid now functioning properly
- Improved error checking and key shifting control in special protocols

Give it a try....send comments

Mark Pierson · Post by **Mark Pierson** » Wed Mar 17, 2004 1:28 pm

e34m5 wrote:- Notes display on the grid for both keymoves and macros

One minor thing... you're allowing mutli-line notes, but can only display a single line in the grid. Unless there's a need for a "War and Peace" length notation, I think a single line edit box would be sufficient.

e34m5 · Post by **e34m5** » Wed Mar 17, 2004 1:57 pm

True...however the grid will display up to 255 characters. So the multi line in the dialog is there so you can see what has been typed..

Sheesh..you guys are so needy

e34m5 · Post by **e34m5** » Wed Mar 17, 2004 2:49 pm

One more load...this time with column resizing saving in keymoves and macros grid

DGG · Post by **DGG** » Wed Mar 17, 2004 2:57 pm

Paul, I just downloaded the latest version. Sad to say, there's still a little work to do.

Re shift/unshift:
1. Once you shift or unshift a key, you must select another key and then reselect the original one before a further shift operation is possible. For example, if you unshift a key and then want to restore it to its shifted or x-shifted state, you can't without deselecting and reselecting.

2. No shift/unshift operations are possible unless the keyname on which the operation is to be performed in highlighted. For example, when you select a key field, the keyname is highlighted. But, if you click somewhere else in the window (other than on another key field), the last-selected field remains selected, but is no longer highlighted; hence no shift/unshift operation can be performed. (I just realized that this is likely the cause of 1. above since, once a shift operation is performed, the new keyname is no longer highlighted.)

3. The "unShift" button is enabled whether or not the selected key is shifted.

UI:
1. Now that the column names in the Keymove window have been "scrunched up" to make room for the Notes column, several of the column headers need two lines to display, but they don't get two full lines. For example, for Bound Device, I see "Bound" and below it, only the upper part of "Device".

2. In the Special Protocol Builder dialog, there is a lot of wasted space. On my system, I need the entire height of the display for that window. (That means it would never all be in view on 800x600 resolution. It would seem helpful if you reduced the width of the key field window to the width of the key fields and, in height, to the height necessary for 13 key fields. This should allow the dialog to be fixed size and displayed in full irregardless of resolution.

3. Just a personal preference, the two headers "Buttons for Short/Long Press" would look better if they were shown above the key field windows, rather than in the windows.

4. On the topic of fixed size, I understood you were going to enlarge the "Special Protocol Builder" button. If you have, please note that it is still displayed at the same size on my system. This XP idiosyncrasy is becoming a real pain.

Don

e34m5 · Post by **e34m5** » Wed Mar 17, 2004 3:19 pm

Re shift/unshift:
1. Once you shift or unshift a key, you must select another key and then reselect the original one before a further shift operation is possible. For example, if you unshift a key and then want to restore it to its shifted or x-shifted state, you can't without deselecting and reselecting.

Yes, I know. It has to do with the way Delphi treats the focus. I needed to have a unique way to identify the cell in question.

2. No shift/unshift operations are possible unless the keyname on which the operation is to be performed in highlighted. For example, when you select a key field, the keyname is highlighted. But, if you click somewhere else in the window (other than on another key field), the last-selected field remains selected, but is no longer highlighted; hence no shift/unshift operation can be performed. (I just realized that this is likely the cause of 1. above since, once a shift operation is performed, the new keyname is no longer highlighted.)

Correct. This mimics the functionality in the macro dialog. Before the buttons are available you have to check if the key is shiftable.

3. The "unShift" button is enabled whether or not the selected key is shifted.

Correct. I did this because if you recall are editing a keymove that already has a shifted variant you may want to unshift it. Since the key in question would not be able to be shifted again then the unshift key would not be available.

UI:
1. Now that the column names in the Keymove window have been "scrunched up" to make room for the Notes column, several of the column headers need two lines to display, but they don't get two full lines. For example, for Bound Device, I see "Bound" and below it, only the upper part of "Device".

Are you sure you have the latest build. The titles in the keymove grid are now two full lines???

2. In the Special Protocol Builder dialog, there is a lot of wasted space. On my system, I need the entire height of the display for that window. (That means it would never all be in view on 800x600 resolution. It would seem helpful if you reduced the width of the key field window to the width of the key fields and, in height, to the height necessary for 13 key fields. This should allow the dialog to be fixed size and displayed in full irregardless of resolution.

Odd. I tried it in 800x600 with no problem. I will scrunch up the dialog as much as possible.

3. Just a personal preference, the two headers "Buttons for Short/Long Press" would look better if they were shown above the key field windows, rather than in the windows.

Just trying to keep the look and feel. All the other grids use the top row for titles. I did however notice that I did not bold. Will fix that.

4. On the topic of fixed size, I understood you were going to enlarge the "Special Protocol Builder" button. If you have, please note that it is still displayed at the same size on my system. This XP idiosyncrasy is becoming a real pain.

I did. I guess I'll make wider still.

We'll get it all resolved soon...

DGG · Post by **DGG** » Wed Mar 17, 2004 3:58 pm

UI:
1. Now that the column names in the Keymove window have been "scrunched up" to make room for the Notes column, several of the column headers need two lines to display, but they don't get two full lines. For example, for Bound Device, I see "Bound" and below it, only the upper part of "Device".
Are you sure you have the latest build. The titles in the keymove grid are now two full lines???

I didn't when I sent my last e-mail (My e-mail and your's announcing the latest version crossed in cyberspace). Therefore, my e-mail referred to yesterday's version. However, I've checked the latest version(03/17/2004 2:43PM) and I'm still only seeing 1 1/2 lines.

2. No shift/unshift operations are possible unless the keyname on which the operation is to be performed in highlighted. For example, when you select a key field, the keyname is highlighted. But, if you click somewhere else in the window (other than on another key field), the last-selected field remains selected, but is no longer highlighted; hence no shift/unshift operation can be performed. (I just realized that this is likely the cause of 1. above since, once a shift operation is performed, the new keyname is no longer highlighted.)
Correct. This mimics the functionality in the macro dialog. Before the buttons are available you have to check if the key is shiftable.

This operation appears to have changed in the latest version and the problem I was observing no longer seems to exist. However, now, if you enter a new key in one column and then "click" on any field in the other column (or the header), both the newly selected key field and the previously entered field are highlighted.

3. The "unShift" button is enabled whether or not the selected key is shifted.

Correct. I did this because if you recall are editing a keymove that already has a shifted variant you may want to unshift it. Since the key in question would not be able to be shifted again then the unshift key would not be available.

Why can't a previously shifted key that was unshifted be shifted again?

Odd. I tried it in 800x600 with no problem. I will scrunch up the dialog as much as possible.

Perhaps this, and the other UI issues I identified are all manifestations of the XP display idiosyncrasy. If so, I hope you find the problem soon

Don

e34m5 · Post by **e34m5** » Wed Mar 17, 2004 4:01 pm

Have to go now..Don I will address these tonight and post a new one tomorrow.

Tx.

Dabbith · Post by **Dabbith** » Wed Mar 17, 2004 6:31 pm

Nice Job. I really like the idea of special protocols being configured in IR. It was always annoying to have to create them elsewhere and copy them into IR. In fact, they are almost self documenting because you can easily decode them and see what they do. This will greatly reduce my need for notes.

I have just a few suggestions right now. It would be really nice if you could open the special protocols dialog even without entering the setup code and device of a special protocol. Choosing the protocol in the drop down in the special protocols dialog could fill in the device and setup code for you. That way the user doesn't need to remember which setup code is for which special protocol. It would also remove the current bug where you can choose the wrong special protocol in the drop down and get error messages (configure a ToadTog, and try to choose DSM from the drop down).

It would also be nice if Device and Key in the dialog were greyed out. As they are they look like you could type into them.

And to confirm previous bugs, at 1280x1024 I see 1.5 lines of header information for the grid, and the first and last letters of "Special Protocol Builder" are cut off.

I even like the notes section in the dialogs better then my solution of allowing you to edit them in the grid. I've been using my version for a while, but It's inconsistant with how the rest of the grid works.

Capn Trips · Post by **Capn Trips** » Wed Mar 17, 2004 7:16 pm

Just to pile on here.

I have finally downloaded the beta and opened up my Family Room upgrade to look. Everything looks SUPER!

The Keymove labels, although wrapped around and occupying two lines, were fully readable, as the first (heading) "row" of the table automatically re-sized to two lines. The entire KeyMove pop-up window was initially too small to display the Special Protocol Builder/Notes section, but after re-sizing once, it now opens to a full view (even after shutting down IR completely and restarting it).

I think this is a MONUMENTAL improvement in user-friendliness

- now if I could just remember what all of my LKPs, ToadTogs and Macros do

, I could actually utilize the "Notes" section.

On exceedingly minor note: When I first open IRBeta, it opens up into a "maximized" window (as I like it anyway), but the maximized window is not truly fitted to my screen size.

It's about 10 pixels "low", i.e. I can see the Window behind it (or the desktop) just over the top of it, and a fraction of the bottom is hidden behind the Taskbar. If I resize the window and then maximize, it fills the screen correctly. A minor annoyance, but I figured I'd throw it out there.

BTW, I'm running Windows XP Home at 1024x768 resolution.