Error opening SigmaPlot: "the specified macro default library cannot be opened" - sigmaplot

I use sigmaplot ver. 10.0. It was working before but now it has some problem.
When I start SigmaPlot I see:
The specified macro default library can not be opened. Please make sure it is a valid notebook or select another from Tools/Options/Macro.
pop up, but it works well. However, when I type F5 (to use regression wizard), I see:
The equation library file
C\User\Stealth\Documents\Sigmaplot\SPW10\STANDARD.JFL
cannot be used because of the file's permissions attributes
(such as Read Only restrictions)
and there are no regression options (such as gaussian, linear, etc...). The same phenomenon occurs running as administrator. What am I doing wrong? help me please...

I had the same problem with SigmaPlot14. It turned out that OneNote moved all folders from C/user/documents... to C/user/Onenote/documents....
I manually copied all folders back to the C/user/documents... folder and this solved the issue for me.

you can also just edit the settings .ini file so that the it points to the correct folders.

Related

need to recover trados project with translation

I was working on a language translation project in trados on a virtual machine. Half of the work was done and the translated words were exported into a Word docx file. Upon restarting the virtul machine, the project file appears to have been corrupted as trados shows no signs that the project was worked on. When I manually open the sdlproj (trados project) file, trados cannot open the file mentioning the following:
: An error occured whilst trying to determine the file version
I have tried creating a new project and used pre-translate using batch tasks but that did not seem to have imported the previously translated document. I need to figure out how to recover my project so that I can recover the translated document (so I do not have to redo the work) as well as recover the translation memory for trados. The translation memory folder is present inside the original project folder. I would really appreciate any suggestion to further troubleshoot and fix this issue. I have tried their support desk but they do not appear to be available today. Two solutions I observed from their forum suggested:
save the project file with a zip extension, extract the contents and then open the sdlxiff file from there
recreate the project and use pre-translate.
In my case, I was able to open the sdlxiff file from the translated language directory. This opened the project with the text that had previously been translated. I am not certain whether I need to remove the sdlproj file or simply save the project hoping that it will overwrite the corrupted file. In either case, I will update this post once I get an answer to that.

Compilation Error while editing the visual studio solution

I am editing a visual studio MVC Solution. I have edited all the files, assemblies and Project Name etc. But in the end, it is build successfully but when I am going to run this solution it shows an error like shows in the picture.
Actually, TestSolution was the name of my solution which I've changed with RealEstateErp.Now when I am going to search "Using TestSolution " , I don't find anything. Now, what should I do to overcome this problem? Any kind of help will be appreciated.
when they make drastic changes like the namespaces and dll names, the first thing people forget is to delete the old dlls.
I would start with that, make sure you delete everything in bin, obj and all temp files which reside in Windows\Microsoft.Net and then Framework and Framework 64.
Next, check your global.asax file, specifically the front end part. You get to it by right-clicking the global.asax file and selecting the "View markup" option, that one always has a reference to the old namespace and always gets missed.
Finally, make sure you delete all the using statements referring to the old namespace. You don't need those and they will cause a compilation error like the one you are seeing, because that particular namespace does not exist anymore.
Actually, It was on the Web. Config under View Folder.
I've Updated it with the latest solution name and now it works fine for me.
Could you do Ctrl+Shift+F and search your whole solution about Using TestSolution?
You probably will find the word left somewhere.

Proc_common_v_3 not found

I am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael

How can I make Squeak ask me where to fileOut to?

I'm right-clicking a class category and choose fileOut for exporting it to an .st file. The problem is that it never asks me where to save to, instead just choosing a folder by itself (seems to be the same folder containing the image file).
How can I change it, forcing it to actually ask me where to save the file to? Previous Squeak versions (3.9.x) did ask me.
Squeak version is 4.2, OS is Ubuntu.
It looks like if you don't mind filing out twice, the default behaviour in 4.3 is to prompt if you would overwrite an existing file. Something like Class.st already exists, then select choose another name and you can write to the correct place in any directory, albeit with a second copy in the directory with the image.
I've checked in Pharo and it's the same, the menus just offer to file out to a predefined location.
However, it's still perfectly possible to trigger a file out by script. Look for implementors of #fileOut and #fileOutOn: for examples; evaluating something along the lines of `myProgramEntity fileOutOn: aFileStream' should do it.

Delphi 7 keeps using old outdated form

Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.

Resources