JP1 Remotes

Hi. When running the program I get an error saying it was unable to initialize the driver. I have it in the same directory as IR 4.02, which runs fine. I am running 98SE.

1. On the Key Moves tab none of the four right-click options work.
2. On the Devices and Protocols tab right-clicking on the left-most pane gives four options. I don't think Clone should be there.
3. The Add Shift and Insert Shift buttons don't work on the Scan/Fav tab.

Keep up the good work.
Mike


Juppers: If you are trying trying (New, modifications, Upload), instead try (Download, modifications, Upload). That fixed a similar problem I was having.

First of all, I think you've advanced the state of the art significantly. Please view the following comments in the context of constructive criticism reflecting my personal preferences.

1. I agree with Mark. The resizable window/scrollbars allow me now to view the whole window. However, other IR windows are properly sized when they're initially brought into view to display the whole window. This one should probably do the same. As well, consistency in presentation, e.g., style, fonts, etc should be maintained whenever possible.

2. While the Normal/Shift/X-shift radio buttons are essential for input, one shouldn't have to look at them afterward to see which mode of a key is selected - especially since the contents of the line-item to which they apply is overwritten immediately upon selection. The relevant line-item should say "shift-" or "x-shift-", just as for macros.

3. Selection of a line item should not result in it being overwritten by a "Select an Item" pull-down menu. I suggest you make it the same as the Type and Value fields under the General Tab, i.e., the item in the field remains displayed as the current item in the pull-down menu.

4. Do we need to have a second page? Couldn't the Special Protocol Builder dialog be integrated with the Keymove dialog. Once you adopt the same font/presentation style, there would seem to be lots of room to the right of the "Device:" window.

5. I too am having trouble decoding ToadTogs. The first one I tried, failed. "$B1 $C3 $DF $C2 $E4 $F7 " decoded as "Toggle 3, Test only", which is correct, but the rest of the keymove was ignored - no keys were shown for either action.

That's it for now. I'll take another look once you post the next upgrade.
Don

To all - I uploaded a new version and named it IRBETA.exe

DGG wrote:First of all, I think you've advanced the state of the art significantly. Please view the following comments in the context of constructive criticism reflecting my personal preferences.

Thank you and keep the comments coming...my only goal is to create something we all like and use

DGG wrote: I agree with Mark. The resizable window/scrollbars allow me now to view the whole window. However, other IR windows are properly sized when they're initially brought into view to display the whole window. This one should probably do the same. As well, consistency in presentation, e.g., style, fonts, etc should be maintained whenever possible.

I had them fixed size originally. Then some folks couldn't see the whole screen. I now have gone back to fixed size and is identical in size to the keymove screen. I also made all the fonts the same.

DGG wrote:While the Normal/Shift/X-shift radio buttons are essential for input, one shouldn't have to look at them afterward to see which mode of a key is selected - especially since the contents of the line-item to which they apply is overwritten immediately upon selection. The relevant line-item should say "shift-" or "x-shift-", just as for macros.

This was done as suggestion from an early tester...I really struggled with this and finally just settled on this. You don't have to look at them after selection as it always resets to normal after the use. The normal was added so that people wouldn't be confused on the state

DGG wrote: Selection of a line item should not result in it being overwritten by a "Select an Item" pull-down menu. I suggest you make it the same as the Type and Value fields under the General Tab, i.e., the item in the field remains displayed as the current item in the pull-down menu.

Fixed

DGG wrote: Do we need to have a second page? Couldn't the Special Protocol Builder dialog be integrated with the Keymove dialog. Once you adopt the same font/presentation style, there would seem to be lots of room to the right of the "Device:" window.

I started thinking this way and then opted not to go there. As you might imagine there is a lot of code in the keymove screen and I only wanted to make the least necessary changes so as to not muck anything up. Also I felt that since not all keymoves are of the special protocol variety that all that extra stuff may actually be distracting. Any way..developers prerogative

DGG wrote:I too am having trouble decoding ToadTogs. The first one I tried, failed. "$B1 $C3 $DF $C2 $E4 $F7 " decoded as "Toggle 3, Test only", which is correct, but the rest of the keymove was ignored - no keys were shown for either action.

I think I found a stupid developer error deep in the bowels of the code breakdown...try it again...

Some one else had reported that the notes were not taking into account shift or xshift...that was a correct..I fixed it...another stupid programmer error

DGG wrote:That's it for now. I'll take another look once you post the next upgrade.

As I mentioned above..please feel free to comment..so long as they aren't attacks I will take them all

Paul

e34m5 wrote:I had them fixed size originally. Then some folks couldn't see the whole screen. I now have gone back to fixed size and is identical in size to the keymove screen. I also made all the fonts the same.

I still get nothing past the Special Protocol Builder Button button (WinXP).

If I can make a suggestion, maybe the SP button should be placed alongside the OK and Cancel buttons, instead of being that big thing you have now. Then, the dialog just needs to be size large enough to accomodate the Notes section.

Mark Pierson wrote:I still get nothing past the Special Protocol Builder Button button (WinXP).

That was why I had originally asked him to add the resizing of the keymove window. I just now had to open the regular IR then resize the window, close IR and open the beta to get the bottom buttons in view.

EDIT: Win XP also

Just downloaded and tried out the latest IR 4.03 Beta. The new features are good, but there are still some nagging UI issues that I noticed.

1) Again, perhaps due to the fixed window size etc, but the "Special Protocol Builder" button is only half visible on my machine and I can't even see OK/Cancel. I agree with Mark that perhaps the button could be next to OK/Cancel rather than below. (WinXP 1280x1024, "normal" fonts)

2) I am failing to see how/where I can add a note to my keymoves. Maybe you removed it, or broke it, or perhaps I just don't know where to find it. But, in any case, I don't see it.

The following issues are in the new Special Protocol Builder window:
3) The font size and/or style for the words "Protocol" etc. are not the same as the remainder of the window.

4) When I click in the right-hand list box, the text "ComboBoxGrid2" appears within. Note that this does not happen on the left-hand list box.

5) Also, when I click in the right-hand list box, the text in the selected entry in the left hand box disappears.

The "good news" is that my ToadTogs seem to be decoding correctly...

Matt

Ok...the beat goes on...

I made several cosmetic changes based on feedback..I also found some code that did auto resizing on the keymove screen...I changed that a bit so let's see if that cures the issue some of you are having with that.

I moved the spec prot button...and I also moved the prot, dur and cond stuff a little.

One thing that I forgot to mention on the number of key steps..It is way to much work to write code to control the number of steps in each side..so I made both sides 13 steps long...IR will check upon exiting the spec prot screen whether you violate the limit...as far as number of steps on each side it is up to the user to make sure it is correct.


Ok let's try this one......

Bump

So far, so good. I can now see everything, but the fonts still aren't right inside the Protocol Builder dialog. I haven't really tested it thoroughly yet.

Does the Special Protocol stuff use any of the settings from the RDF (like the recent additions to support ECC)? If so, maybe instead of the SPB button, you could have a drop-down that lists the SP's available for the current remote.

The decode and window size problems I reported earlier are now fixed. However the Special Protocol Builder key now reads "pecial Protocol Builde"

Re your comment on the number of keysteps, 13 and 13 doesn't seem appropriate. The first action is limited to 7, the second is limited to (12 - length of first), so it shouldn't allow more than 12 entries. (The only special protocol keymove that permits 13 steps is DSM.) Also, while I don't mean to be argumemtitive, you have to be able to count the number of entered keystrokes in the first action since that number must be recorded in the keymove. Consequently, it's hard to visualize why you couldn't also count the number of steps in the second keymove and give an error if the totals exceeds 12?

Re your earlier comments about the shift/x-shift indicators, I not sure I understand the comment. In any case, the operation still is not adequate. The radio buttons do not reset to normal afer entry nor do they appear to permit entry of a shifted or x-shifted key.

I've got a few other minor "nits", but I'll wait until the feature is working before raising minor UI items.

Don

DGG wrote:The decode and window size problems I reported earlier are now fixed. However the Special Protocol Builder key now reads "pecial Protocol Builde"

Hmm..I tried it on both my PC's and it looks fine

Re your comment on the number of keysteps, 13 and 13 doesn't seem appropriate. The first action is limited to 7, the second is limited to (12 - length of first), so it shouldn't allow more than 12 entries. (The only special protocol keymove that permits 13 steps is DSM.) Also, while I don't mean to be argumemtitive, you have to be able to count the number of entered keystrokes in the first action since that number must be recorded in the keymove. Consequently, it's hard to visualize why you couldn't also count the number of steps in the second keymove and give an error if the totals exceeds 12?

What I meant is that I made both sides the same size. IR checks to see if the total number of entries exceeds 13. So in DSM you get 13 strokes and every one else as you say is really 12 plus the first entry for control

Re your earlier comments about the shift/x-shift indicators, I not sure I understand the comment. In any case, the operation still is not adequate. The radio buttons do not reset to normal afer entry nor do they appear to permit entry of a shifted or x-shifted key.

Working fine for me???

I've got a few other minor "nits", but I'll wait until the feature is working before raising minor UI items.

Ok...not being rude...but I can't replicate some of what you guys are seeing

I am not seeing any of these problems either so I am not sure what to suggest. The only thing I can think of it that it may be related to screen resolution if you are not set at 1024/768 where it seems to work fine.

This however would not answer why the normal, shift and xshift isn't working. When I want to enter a shift key I just first select the radio button for shift then pick the button I want shifted in the window. After selecting the button the radio switches back to normal just like it should.

I also don't think it is worth adding the code that would be required to change the amount of rows available on the left or right whenever a button is added or deleted from either side. Since it is tested in the end it is just not worth the overhead of the coding. It may be worthwile putting helper notes on the bottom that state the limits and leave it at that.

e34m5 wrote:It is way to much work to write code to control the number of steps in each side..so I made both sides 13 steps long...IR will check upon exiting the spec prot screen whether you violate the limit...as far as number of steps on each side it is up to the user to make sure it is correct.

I hope it was only "way too much work" for the beta release?

Isn't the whole point of adding a feature like this is to make it easier for the user? As Don said, you must already have the necessary data available since it's being encoded in the hex string. Imposing a requirement like this on even an experienced JP1 user is not acceptable, IMHO.

If any of the other JP1 developers had the same "it's too hard" attitude, the quality of the tools certainly wouldn't be what they are today. My apologies for being candid, but I think the JP1 community deserves the best we can provide, whatever the cost.

Hmm..I tried it on both my PC's and it looks fine

Keep in mind that users can customize their display preferences. You've either got to dynamically resize the button based on the selected font, or give it a shorter, more generic label (or use a different UI control like the drop-down I suggested).

but I can't replicate some of what you guys are seeing

Welcome to the wonderful world of Windows programming! If you think this is hard, you ought to try Excel sometime!

If I select shift/x-shift first, as Nils describes, it works. But, if I select the button first and then the shift/x-shift (which is how it's done for macros), it doesn't work. I think this aspect of macros and keymove entry should be the same - or at least similar. Of course, if you can make it work both ways, .... Incidentally, the way it is, it's rather cumbersome changing a non-shifted key to its shifted counterpart and vice versa - especially the latter.

As for "pecial Protocol Builde", I'm using 1024x768 with standard size font, though I'm not sure Windows' setup font size is relevant here. Sorry, I don't have any suggestiuns as to why your's and Nils' work and mine doesn't. I don't have a similar problem anywhere else in IR or the other JP1 tools (that I'm aware of).

As for 13 and 13, I guess I don't care how many blank spaces there are. (But, using the number of blank spaces as a guideline to the user as to how much data can be entered does seem helpful.) However, you really must check for the limit of 7 on the first action, since only three bits are available for string length storage. If you rely on the user and you just lob off the last three bits, it seems to me you could have a situation where someone enters 8 steps, but you would record the length as 0 without a error message. That doesn't sound like a good idea. IR proper has no way of checking this after the fact.

DGG wrote:If I select shift/x-shift first, as Nils describes, it works. But, if I select the button first and then the shift/x-shift (which is how it's done for macros), it doesn't work. I think this aspect of macros and keymove entry should be the same - or at least similar. Of course, if you can make it work both ways, .... Incidentally, the way it is, it's rather cumbersome changing a non-shifted key to its shifted counterpart and vice versa - especially the latter.

If you can think of a better way then go ahead and do it

As for "pecial Protocol Builde", I'm using 1024x768 with standard size font, though I'm not sure Windows' setup font size is relevant here. Sorry, I don't have any suggestiuns as to why your's and Nils' work and mine doesn't. I don't have a similar problem anywhere else in IR or the other JP1 tools (that I'm aware of).

I have tried all resolutions on two PC's with no problems

As for 13 and 13, I guess I don't care how many blank spaces there are. (But, using the number of blank spaces as a guideline to the user as to how much data can be entered does seem helpful.) However, you really must check for the limit of 7 on the first action, since only three bits are available for string length storage. If you rely on the user and you just lob off the last three bits, it seems to me you could have a situation where someone enters 8 steps, but you would record the length as 0 without a error message. That doesn't sound like a good idea. IR proper has no way of checking this after the fact.

Encoding the values and controlling the steps in the grid are to completely different things...I will check the 7 limit on the first action (for non DSM)and the total for 13

Mark - I don't appreciate your sarcasm...I've been programming in Windows since the mid 80's. As far as EXCEL is concerned that's not a real development platform..that's why there never has been a real application written in EXCEL.