Moderator: Moderators
That wasn't sarcasm, it was humor (hence the emoticons). I know all to well that many problems can't be replicated (especially when you're supporting multiple versions of a product, and none of them behave the same). If developing in Windows (on any level) was easy, nobody would hate Microsoft!e34m5 wrote:I don't appreciate your sarcasm...
It seems to me the more the various parts of a tool can have consistent operation, and the simpler that operation, the better. One way to do both for Special Protocol Builder would be to allow the Normal/Shift/X-shift radio buttons to operate directly on the contents of the currently selected field. If the field is empty when a variant radio button is "pressed", upon selecting a base key, the desired variant would be entered automatically. If the field is not empty, pressing a variant key would cause the field to change to the selected variant. That's sort of like "having your cake and eating it too". (At the risk of pressing my luck, pushbuttons might be more appropriate than radio buttons if you adopt this mechanism.)If you can think of a better way
I have tried all resolutions on two PC's with no problems
ForgivenDGG wrote:Since you seem to have forgiven Mark, perhaps you'll allow me to try again.
It seems to me the more the various parts of a tool can have consistent operation, and the simpler that operation, the better. One way to do both for Special Protocol Builder would be to allow the Normal/Shift/X-shift radio buttons to operate directly on the contents of the currently selected field. If the field is empty when a variant radio button is "pressed", upon selecting a base key, the desired variant would be entered automatically. If the field is not empty, pressing a variant key would cause the field to change to the selected variant. That's sort of like "having your cake and eating it too". (At the risk of pressing my luck, pushbuttons might be more appropriate than radio buttons if you adopt this mechanism.)
I need to revisit this. I changed the size of the button based on an earlier comment. I did not change anything else associated with the othe fields. Frankly I am not sure what is going on. But I do recall from my own previous IR expereince that they are some quirkenesses in the whole resizing thing. Typiclly when we create dialogs we make them fixed and check that they fit in any resolution. In WinXP there may something going on due to the style it uses. I have WinXP at home but use the standard Windows style.I don't think it's got anything to do with resolution. As I said yesterday, changing resolution and/or Windows font size has no effect. However, I've noticed two things since last night. First, between the last two versions of IRBeta, the "Special Protocol Builder" button width went from nearly the full width of the dialog box to exactly the width of the EFC/Hex Cmd entry window. I also noticed that most of the other button, drop-down menu and entry window labels on that page are being clipped. For example, EFC/Hex Cmd is displayed as "EFC/HEX Cm", Hex Cmd is displayed as Hex Cm" - with the "m" clipped a little - even the last "e" in Device Type is clipped a little. But, this applies also to IR.exe, suggesting a fundamental dialog layout issue - at least where Windows XP is involved. I guess I'd gotten so used to the clipping in IR that it wasn't apparent until "pecial Protocol Builde" popped into view.
No problem.Paul, I really am trying to be objective here (and helpful).
Don
Just checked Microsoft Support Center. Knowledge Base article #283055 discusses a problem that may be relevant. Apparently, programs that are not Unicode compliant will display dialog boxes differently in multi-language versions of Windows XP (which I have) depending on the user's selected locale. I don't know whether or not IR falls into this category. I've experimented by setting everything to English (US)/United States without apparent effect. (I'm in Canada.) Just thought I should mention it.Just to clarify. Is WinXP the only case where we are having problems. If I can narrow it down then I can do some testing using the WinXP style.
That's probably because everything seems to work now. I've just been through a selection of T/Ts, DSMs and D/LPKs and didn't find any other problems.BTW, very few comments on the actual decoding and encoding of the protocols. Other than the TT fix I have not heard anything else on that.
No, I created a new folder for it, then copied over the text files from the 4.02 folder because IR uses them to try and guess as to whether it's being run from within the zip file or not.e34m5 wrote:Just a stupid question...are you running the Beta in the same directory as 4.0.2...that would make a difference..
I don't recall any on else reporting this problem...The Robman wrote:No, I created a new folder for it, then copied over the text files from the 4.02 folder because IR uses them to try and guess as to whether it's being run from within the zip file or not.e34m5 wrote:Just a stupid question...are you running the Beta in the same directory as 4.0.2...that would make a difference..
I must not be tracking with you becasue it seems to be working fine...Perhaps I'm just not duplicating the order of your steps correctly...Nils_Ekberg wrote:Paul, looks good but one minor problem. Unless you specifically select a blank cell after changing a state and selecting another button to change the change goes to the prior selection. In other words pick a button in the right column and change it's state then select a button in the left column and try to change it's state and the change will go to the right column. If you select a blank cell in between then it works fine. May not be resetting the cell selection flag.
