JP1 Remotes

The issue with the performance had been noticed by Nils and has already been fixed

Sorry, Paul. I repeated last evening's process with the latest version and had the same performance/space problem. The first 9 notes are OK. The tenth had 3 full lines of spaces following it. The 11th is OK. The 12th had 10 full lines of spaces following it and the 13th had 23 lines of spaces after it. As before, the processing time for each of the latter notes was very significant - being close to 30 seconds for the last (on a 2.4mhz machine). I chose to stop before Windows declared the program unresponsive.

On the positive side, all the notes now "play back" properly.

The <CTRL> issue is because I am using just straight txt fields.

It's a "tab" issue; use of <CTRL> was necessary to enter the tab into the field, since a simple tab moves the focus to another field. Anyway, the display of a note in the Notes field in the Macro (and other) dialogs should be consistent with its display under the Macro (Keymove) tab (no pun intended).

And now, a final plea. Please make the SPB dialog larger on opening so that I (and others) don't have to do a dialog move followed by a resize to bring the OK/Cancel buttons into view. In addition, maybe you would consider adopting the scheme IR 4.02 (not IRBeta) uses to resize the Keymove dialog, i.e., when the dialog is resized, various elements in the dialog expand/collapse before essential controls/fields are affected. (For IRBeta, you seem to have implemented a different scheme to resize the Keymove dialog.) The IR scheme should be applied both to IRBeta's Keymove and SPB dialogs.

Paul, I'm not trying to drag-out this last issue. However, there are a whole class of users out here whose computers seem to be configured differently from yours and who are experiencing troublesome symptoms you seem unable to duplicate. Enlarging the dialog on opening and changing the resizing scheme will avoid the difficulty.
Don

I found another minor issue. If you edit a Keymove or Macro that has a note, and change the bound key or the Shift/Xshift status of the current bound key, the note "disappears". If you change the key back to what it was originally, the note "reappears". Upon clicking OK, the note needs to be unbound from the old key-combination and bound to the new key-combination.

DGG wrote:

The issue with the performance had been noticed by Nils and has already been fixed

Sorry, Paul. I repeated last evening's process with the latest version and had the same performance/space problem. The first 9 notes are OK. The tenth had 3 full lines of spaces following it. The 11th is OK. The 12th had 10 full lines of spaces following it and the 13th had 23 lines of spaces after it. As before, the processing time for each of the latter notes was very significant - being close to 30 seconds for the last (on a 2.4mhz machine). I chose to stop before Windows declared the program unresponsive.

On the positive side, all the notes now "play back" properly.

The <CTRL> issue is because I am using just straight txt fields.

It's a "tab" issue; use of <CTRL> was necessary to enter the tab into the field, since a simple tab moves the focus to another field. Anyway, the display of a note in the Notes field in the Macro (and other) dialogs should be consistent with its display under the Macro (Keymove) tab (no pun intended).

And now, a final plea. Please make the SPB dialog larger on opening so that I (and others) don't have to do a dialog move followed by a resize to bring the OK/Cancel buttons into view. In addition, maybe you would consider adopting the scheme IR 4.02 (not IRBeta) uses to resize the Keymove dialog, i.e., when the dialog is resized, various elements in the dialog expand/collapse before essential controls/fields are affected. (For IRBeta, you seem to have implemented a different scheme to resize the Keymove dialog.) The IR scheme should be applied both to IRBeta's Keymove and SPB dialogs.

Paul, I'm not trying to drag-out this last issue. However, there are a whole class of users out here whose computers seem to be configured differently from yours and who are experiencing troublesome symptoms you seem unable to duplicate. Enlarging the dialog on opening and changing the resizing scheme will avoid the difficulty.
Don

No prob..

Please post your txt file as well so I can loaded and see it in action..tx

Three files posted: two notes files: File 1 and File 2, and the matching configuration file.

Things get curiouser and curiouser. When I checked the notes file from earlier today before posting it, I found all the spaces were gone (but see below). So, I deleted it and started again. I transcribed all 20 of the earlier notes by cut and paste from a MS Word file. The last one took 12 seconds to process. (I guess I exaggerated a bit earlier.) Then I "saved" and looked at the notes file with Notepad. It was a very large file and the last 5 notes were not displayed. Presumably the file size was beyond Notepad's capacity. I then tried saving (with Notepad) under a different name for posting. Windows declared Notepad non-responsive after a brief period. I closed Notepad and re-selected IRBeta as the active task under Windows. Windows declared it too as non-responsive. (I gather IRBeta couldn't handle the large file either.) So I forced IRBeta to close. I then re-opened the notes file with Notepad and now it was considerably shorter - presumably the part that IRBeta managed to save. That file is File 1 and it contains the spaces I mentioned earlier.

Then I closed everything and started again. However, this time, I stopped after adding 15 notes, the 15th being the last note that appeared with Notepad in the previous iteration. I then "saved" and opened the notes file with Notepad. Notepad showed the expected, i.e., lots of spaces after the 10th and succeeding notes. I saved this file with Notepad (File 2), which took in the order of 15 seconds.

Once again, I closed everything and restarted IRBeta. All 15 notes I had entered displayed properly. Imagine my surprise, however, when I closed IRBetat and checked the notes file with Notepad and found all the extraneous spaces had been deleted. So, apparently, IRBeta eventually detects the extraneous spaces and deletes then, after which all seems well.

Like I said, curious.
Don

Don

I think the issue is with extraneous characters like CR/LF, TAB, etc

I figured out (with Dabbith's) help how to make sure the CR/LF are properly treated and displayed..I;m now working on the TAB thing

Don, I would be willing to bet that the problem was with all the extraneous (un displayable) characters that MS Word wraps around each word and/or sentence and also pads the end of text with all sorts of Word control chars. Approx. 2/3 of a word doc is control chars. Neither Notepad or IR would know how to handle them and tries to convert them to something it understands which is basically spaces, tabs and line end chars. Eventualy the file got cleaned up by IR and notepad which seems like it made the problem go away.

Nils, if it happened on every note, I be inclined to suspect the same thing. And, we're talking literally thousands of extraneous spaces between notes near the end of the notes file.

I can't speak for IR, but Notepad handles the MS Word file without difficulty - albeit displaying gibberish throughout most of it. In any case, a cut and paste from MSWord to Notepad, only passes the text characters.

But, just to be sure, I repeated the process yet again. There are no extraneous spaces after notes 1-9. But, there 255 spaces after the 10th, none after the 11th and 1024 (or about) after the 12. Do those number sound like coincidence? The only thing that noticeably varies from previous tries is that the absence of spaces after the 11th notes.
Don

Ok let's try this beta.

I added code to deal with CR/LF and TAB...don't know why there would be all those extra characters.

Ok in orde to make this work I'm converting those CR/LF's and TAB's to characters no one will use and saving the ini file like that. Then when I read it back in I do a reverse replace (so when you see odd characters in the ini don't touch them)

In order to see this work you have to open the note and do something to it, otherwise IR doesn't think you made any changes. I made a note that looks like this for testing

1TAB2TAB3CR/LF
4TAB5TAB6

Worked great (I hope)

Sooner or later you guys are going to run out of bugs (I hope no one thinks I am a first time programmer)

BTW, what is the record for replies on one post

Didn't check the space problem since you implied it hadn't been fixed.

Re the tabs, what I had hoped to see was notes displayed identically, whether in the Notes window of the Macros/Keymoves dialog or in the Notes column under the Macros/Keymoves tabs.

What you appear to have done is simply replaced tab characters in the Notes colum with a non-printing character. That's an improvement, but why can't the two displays be identical.

Don, not sure where those extra spaces are coming from unless IR was not stripping everything.

Paul, I think you have the record for replies... 12 pages worth so far.

One more bug to report... Everytime you post a new version Yahoo goes down.

Unfortunately the stringgrid does not recognize the TAB. So I replaced the TAB in the grid with a couple of spaces...at least it looks very close to the note in the dialog..

Don't know what else to do at this point...

Nils...you trying to get me back for my earlier comment

That being the case, what you've got now will have to be fine.

Now, just find where those extraneous spaces are coming from.

Don

PS: I just checked to see if you'd enlarged the SPB dialog on opening. Inadvertently, I selected a keymove that wasn't a special protocol and got the error message "Must have $ in the parameter". (I assume this means it's not a special protocol, because there was, in fact, a "$" in the Hex Cmd field.) Then I selected a special protocol keymove and found you hadn't (enlarged the dialog). So, I closed the SPB dialog and tried again to bring up the SPB dialog for a non-special protocol keymove. This time the dialog displayed, without any error message and without any key-field windows. Then I returned to the Keymove dialog and clicked on SPB again. This time, the SPB dialog displayed with a single key-field window with the header "Device Specific Macro". Subsequent "presses" of the SPB button produced the same result. Not earth-shattering, but probably worth fixing in a final cleanup.

Don

I am curious about a couple of things related to the problems you just reported.

1) The issue with the message "Must have $ in the parameter". Had you edited the field on the main keymove tab before you pressed the SPB button or was it an EFC based keymove? If so that answers why you got the message. Paul is making sure it is a hex command(s) before he opens it in the SPB. When you edit the field, like I do I tend to just type the number in without the $ since IR will always save it with the $ if you specify "use hex". You can force this error by opening any hex based keymove and removing one or more of the $'s or opening an EFC based keymove then click on the SPB button.

2) The issue with the main keymove window being too small when you open it. Is this the first time you open it or every time you open it? The reason I ask is that if you go back and forth between IR and IRBeta you will get that because IR is saving a smaller window size. If you resize it in IRBeta and get out of IRBeta and back in it should then be the size you made it until the next time you go back to IR.

Just so you know, the biggest thing Paul is wrestling with is compatability with functions that are already in IR. If he adds something for the SPB or notes and they cause a problem in the old IR he is trying to make it work without changing the old IR. Actually, Mark and I suggested he not make any more changes to the old IR than absolutly necessary. The more he can avoid changing the old IR the better off we all are since changing the old can introduce new problems. I also think that things like the notes should be as generic as possible and not add advanced text functions. In other words it is just to be used for standard text chars. and not formatting chars. like tab since tab and ctrl-tab do other things in IR like go to next field (and a note is just a field) and ctrl-tab to go to next panel.

I hope all of this makes sense and helps you understand why he may be pushing back on or having trouble with certain enhancements.

My $.02

This project started out as just SP. We then progressed to notes. In between there were many other bugs (old ones).

I have and will with pleasure continue to work on IR for the love of it.

In my mind, as a developer and a user there are some things that simply are not worth spending any time on.

As you all probably know it is near impossible to replicate every condition that a user may encounter, heck Microsalt releases stuff with thousands of bugs.

So at this point what I would really like to do is concentrate on finishing this piece.

If there are any major issues we will address them, if not a respectfully request that we start a new list of improvements.

TX

Had you edited the field on the main keymove tab before you pressed the SPB button or was it an EFC based keymove?

The latter. I know why I got the error message - even though the error message seemed a bit obtuse. My concern was the second time I tried it, after loading a valid extended keymove, there was no error message and the dialog opened without key-field windows. On subsequent tries, the SPB dialog opened as for a DSM. Three different responses to the same attempted erroneous action, depending on what I had done earlier. As I noted in my last post, not an earth-shattering problem but, nonetheless, worthy of cleanup eventually.

Is this the first time you open it or every time you open it?

Again, the latter. I started IRBeta, brought the SPB dialog into view, resized it, OK, OK, Save, Exit. Restart IRBeta and the dialog is back to its original size. The resized dialog is preserved so long as one doesn't quit IRBeta, but is back to the programmed size on restart. I appreciate that a work-around is available (move it and resize it every time I start IRBeta), but simply increasing the opening size obviates all that (and I wouldn't think its a big deal to implement).

I hope all of this makes sense and helps you understand why he may be pushing back on or having trouble with certain enhancements.

I was a software developer for many years and I fully appreciate the issues/concerns. I seem to be being singled out as the bad guy here. All I am doing is reporting new problems as I discover them - as Paul asked. I haven't asked for anything to be changed in the original IR (though I acknowledge others have). Indeed, certain things in the original IR have been changed in this exercise and I've suggested they be reinstated. A prime example is the way IR resizes the Keymove dialog - which it also uses for most of IRs tabs. If that mechanism had been retained in IRBeta and also used for the SPB dialog, opening size of the SPB dialog wouldn't be an issue now. The tabs aren't a big deal, but if they're not going to be supported, their entry shouldn't be allowed, or at least they should be treated the same way on entry that they'll be treated subsequently.

I agree that the remaining issues should be prioritized. No doubt some can be deferred. For others, that may not be a good idea. Paul says that notes weren't in the original scope of the job. Since virtually all the newly-discovered issues pertain to notes, maybe notes should be taken out of the first release to give Paul an opportunity to address its problems in a more relaxed atmosphere.
Don