IR Edit and Windows 8.1
Neil Carroll
Posts: 12
I had IR Edit working with Windows 8, but since I updated to 8.1 IR Edit would not start.
I've tried re-installing IR Edit but I get the installer telling me that the .net framework is not installed, even though I ran the IREdit system files installer without any errors.
Any ideas?
Thanks
Neil
I've tried re-installing IR Edit but I get the installer telling me that the .net framework is not installed, even though I ran the IREdit system files installer without any errors.
Any ideas?
Thanks
Neil
0
Comments
I have tried this and it still fails. is there another solution or a newer version of IR Edit.
That said, when you upgrade Win 8 to 8.1, you have to re-install Microsoft.NET framework 1.1, and the IREdit program requires it. Furthermore, .net 1.1 won't install on 8.1. The only solution might be to run it in a virtual machine, unless someone else knows better. AMX really, really needs to fix this tool ...
Click here for updated & non-intrusive steps.
OLD STEPS BELOW
Unfortunately, what is released on the site is the most current.
This is by no means an "official" fix, but it worked for me.
I uninstalled IREdit and tried reinstalling. It barked about not having .NET 1.1 or higher installed. Versions 2 - 4.5 are components installed with Windows 8, however, per Microsoft, 1.1 is unsupported. That being said, I spent some time on Google and I came across a few links.
In this one, someone essentially posted regarding the same roadblock we're facing. Early in the thread, this link was posted, which talked about removing the mess Win 8.1 made of .Net 1.1. Lastly, I used the procedure here to install .NET 1.1. and when all was said and done, IREdit installed & ran fine. I don't think the installation of IREdit is necessary - so it might be worth a try without uninstalling.
Be warned, however, the removal of .NET 1.1 using the tool above apparently "will delete shared files and registry keys used by other versions of the .NET Framework. If you run the cleanup tool, you will need to perform a repair/re-install for all other versions of the .NET Framework that are on your computer or they will not work correctly afterwards."
I personally haven't any issues with my machine after doing the procedure above, but as always, YMMV.
Hi Julian
Currently this issue is being put to software engineering as a feature request, the 2 things I would suggest are to try and run the programme in compatibility mode for windows XP (this is the only version supported) or to downgrade to windows 8.0.
There is currently no timescale for this to be completed but it is being looked into.
Kind Regards
IREdit has not been updated for 7 years. I have been able to make it work with Win 7-64 for a few years. Then I got it to work with Win 8-64. But 8.1 is not working. It's great that AMX keeps coming up with new products but IR Edit is a basic tool.
We should not have to muck around with possibly dodgy software to get one of our main software tools to work with the latest version of windows.
Especially as we have no other operating system alternative.
I automatically got Windows 8 with a new laptop, I shouldn't have to spend days sorting out issues that should have been resolved years ago.
Come on AMX, lets get things updated into this decade...
That worked for Windows 8, but it won't for 8.1, because 8.1 kills .NET 1.1, which IREdit needs.
The link to the procedure to instal 1.1 fails on my Win 8.1 machine. That link references installing it on Win 7, so I'm not exactly shocked, but you must have done something else to get it to work. I'm running IREdit in a HyperV VM, and although it's a royal pain, it's useable. I'd really like to get it on Win 8.1 without jumping through hoops.
http://www.goodjobsucking.com/?p=214
I'm not the kind of guy that really enjoys any holiday, so I tend to work on the days we get off. That being said...
(Skip to the bottom skip the story and go right to the steps.)
I nuked & paved my laptop and installed Windows 8.1 and as I was programming my Netduino, I noticed it was yelling about some error. After some searching, I learned it was because I didn't have .Net 3.5. So, I went into the Control Panel, then to Uninstall a program, and finally to Turn Windows features on or off. I enabled .NET Framework 3.5, which will include .NET 2.0 & .NET 3.0.
After that, I figured I'd try to install IREdit and proceeded to download system files and IREdit itself. Of course, the system files program failed and Windows asked me if it installed correctly or not. I selected that it didn't and let it choose a lower version on its own and after that, it installed itself properly. I check what it was set to, and had the IREdit install program match it - it was Windows XP w/SP 3. It installed properly out of the gates. I then proceeded to open IREdit and all was good.
That being said, it would appear that doing the previous post's steps are not necessary. Essentially, here's what I had to do:
0. Disable UAC (I'm sure this isn't needed, but that's the ONLY change I made after installed Windows. This probably just saved a few prompts.)
1. Enable the .NET Framework 3.5 through Control Panel -> Uninstall a program -> Turn Windows features on or off
2. Set IREditSystemFiles.exe compatibility mode to XP with SP3
3. Set IREditSetup.exe's compatibility mode to XP with SP3.
4. Install IREdit's System Files - it will prompt that it needs to install a framework.
5. Install IREdit.
6. Enjoy!
Let me know if this works for anyone else.
I ask because I have IREDIT "running" in WIN7, it works for loading files and looking at them, even sending them to ports - and one would think it's OK. But any significant manipulation has me visiting the desktop unceremoniously. While the 8.1 issues are different, I bring it up because IREDIT is a bundle of separate apps with a shell making it look like one... and there are many potential failure modes.
Regarding IREdit being a bundle of separate apps, I have to disagree -- particularly because I'm looking at the source code right now. While many of our programs share components across them, IREdit does not appear to use separate applications and put them under a single shell, much like NetLinx Studio does (the compiler is a separate executable, as is the file transfer portion, Dip Switch, file compare, etc.) It is true that the IREdit Visual Studio solution uses several projects to generate dependent DLLs, but there is only one executable that is generated and needed.
Back on to the original thread - more to come tomorrow after some obligatory testing.
I'll see if I can muster up a machine to go from 8 to 8.1 - but I think this'll be the fix for this problem.
John - I'm failing to understand how 'it can crash in an operation, but keep running for others'. Could you please explain? You're right though that it doesn't transfer a workspace, but neither does KeypadBuilder or TPDesign - they transfer only saved files.
Neil - would you mind trying my suggestion?
Many times (both before Win7 and particularly since) I'll try to do something and get a crash dialog, but the UI stays up, and some things continue to work. Not that I expect it to be stable at that point... but it looks like some sub-part crashed and left a shell running.
I think TPDesign does transfer the workspace... I've been doing this a long time and can't imagine that I have coincidentally saved my work before transfer every time so as not to notice...
It has two options, "Send to Panel" and "Send File to Panel", the first does send the workspace... it makes a temp file on the way, but it's rational. In IREDIT, you don't get any hint that your workspace isn't going anywhere without saving.
And the concept of being unable to save the workspace as anything but overwriting the file it came from is pretty "unique". The "Save Copy As" item is a kluge to get out of that corner by allowing you to copy the original (not yet overwritten" source file to another place/name, so when you do overwrite the original, you have a copy. Arcane. Of course once you get the zen, you start off by making a copy outside IREDIT and don't risk opening your original file.
TPD4 sends the workspace, and you need not save, as I thought, as it should be, IMHO.
I took our standard project, deleted a number of buttons from the startup page and made one that said NOT SAVED.
Then I didn't save it... Choose "Send to Panel" (not "Send file to panel").
It shows "generating files to send" and then does the deed.
My panel now says NOT SAVED and there no saved version anywhere that says this. Well, none that I made... clearly there was one in the TPD4 work folders, at least for a moment. And when I went to exit without saving, it dutifully warned me that I hadn't saved. As good design would suggest.
This is of course NOT to suggest that not saving is good practice. But when you are looking at a workspace you are manipulating, and choose a function Called SEND, I kind of expect the workspace to be what is sent. And it is so in 99% of the software I use... IREdit is in the other 1%. And the issue is aggravated by the UI failing to give you a hint of that fact. And near 100% of the dealers I've trained (after they have had 1-2 weeks of AMX training already) still have no idea what SAVE COPY AS is for, or assume it's an oddly worded path to save the workspace as a new file. This of course ends badly when they edit a file, "Save Copy As", "Send", then exit. All their work is gone, they have two copies of the original unedited file, and the one in the NetLinx is the original too.
My solution has been to tell them to think of IREDIT as a shell for a bunch of monolithic apps, and and no matter what they do, every function operates against the SAVED file, and don't expect that unsaved changes in any aspect of the program will have any impact on other areas. Whether or not IREDIT is a shell, this mindset heads off a lot of frustration from the failure of otherwise intuitive actions.
Works a treat now after getting a head ache! Thanks!
Oddly, after the first installation on a clean new WIN10 (using compatibility), it ran and loaded an IR file for me. Then I selected a single command entry, and did a control/c copy. Instant crash. Now IREDIT crashes on load, never gets past the splash screen. So I uninstall IREDIT, and it won't uninstall completely. So I reinstall over the top, same result, it crashes on the splash screen.
So I try to reinstall the system files, and the installer says it's done as soon as I press START.
And there's no separate uninistall for the system files.
So I'm all done. No more IR work on my newest and best work computer.
Insane that I need to keep a separate ancient computer with a discontinued operating system (XP) with me on every job in case I need to manipulate IR files.
And hope it doesn't die, because installing XP is nearly impossible today...
So I'm off exploring Hyper-V and Virtualbox to try to make IREDIT work in captivity. Because my hours of trial and error cost nothing of course.
I presume AMX has lost the source code for IREDIT or they'd have spared us these years of misery with a tweaked release sometime in the last 11 years.
I'll let you know how it goes. I know I'm not alone in this.
You are not alone. The lack of a functioning IR editing tool is a serious drawback to using AMX.
Agreed. I feel like someone at AMX was betting the farm that IR would die eventually removing the need to keep funding the develpment of IREdit. Having been involved in a tech startup - I can completely understand the high cost of maintaining an application. But, not having a viable IR solution is sometimes a deal killer. I oft' wonder if it might just be easier in the long haul to just give us access to the IR ports not by means of uploading a file, but allowing us to just send the raw hex values ourselves? After all we just need to know those values and the baud rate to send them and the repeat frequency. As a programmer, I honestly wouldn't mind that at all. In fact, I'd prefer it. It's fairly easy for me to maintain a huge library of IR hex codes and be able to change them on the fly if needed.
Who's with me?
Since would I usually use RTI's software to export hex codes into IREdit (when it worked), this would be a fine solution for me.
In fact, any solution at this point would be better then the current state of affairs.
FYI on the virtualization of my XP environment, no joy yet. I did manage to kill my WIN10 install trying. So there's that.