I have a lisp routine (quite lengthy) that was written for AutoCAD 2012, works in 2012.
We have upgraded to 2014 and need to get this lisp file up and running smoothly, parts work but I get the error above. I think I have a problem with open dcl and its current version for ACAD 2014.
2014 is version 19.1 is there a dcl version 19.1. My lisp routine loads in 2014 but the associated dialog box does not show up. My users tell me it was working and has mysteriously stopped working a couple days ago.
I have 0 knowledge of the autolisp language.
Any help offered is appreciated.
You need to install the current OpenDCL Runtime. Get it here
Related
I am using VBA hosted in a drafting program called MicroStation. I have been using MSCOMCTL for the last few years to use controls such as Tab Views and ListViews. I have come back from a work trip and found my home PC to have a Windows Updated and im assuming that its broken it as i have found many articles relating to similar problems.
MSCOMCTL will register and says it has succeed, but still shows as missing in the VBA IDE. Usually i can just use the regsvr32 command and it will work no problems.
I have researched alot and have found a heap of solutions, but none work for me. The main one seems to be to run.
regsvr32 c:\windows\syswow64\regtlib.ocx
But i cant find regtlib.ocx on my Windows 10 - 64 Bit PC.
With this VBA Program, the company where it is deployed is very restricted on what the users can do so im hoping to find an alternative to MSCOMCTL but still within VBA that i can somehow package / compile within my VBA file and doesnt need to be installed onto the PC. Either that or a solution to get the file working. I have been reading article after article and trying a heap of things over the past few days but nothing has worked. It seems at the moment that my best option is to redesign the forms without the Tab Control and List Views. But i find this crazy as they are microsoft files.
Thanks in advance!
So far i have tried the below (plus a couple more escape me at this time)
*Replacing MSCOMCTL.ocx with a downloaded version (backed up the original just in case)
*Replacing MSCOMCTL.ocx with a version installed with Office 2013, located under the program files x86/office/root etc.
*Registering MSCOMCTL in safemode to ensure it wasn't in use.
*Searching the C drive for regtlib.ocx as that has been known to fix it.
*I did find an alternative, but requires various files to be installed onto the PC which wouldn't work in this case with the company's restrictions
*I know this is not a new issue, but most of the posts are a few years old and their solutions (usually re-registering the file) have not worked for me.
Thanks everyone. Problem has been solved. It was a combination of a couple of things based on dbmitch's answer.
By unchecking the missing control, closing down the host program and rebooting. Then opening up the VBA file and searching for the "Microsoft Common Controls" and selecting it. Even though the text was the exact same as the "Missing" one it seems to have done the trick.
I did do that step, but didn't close down the program and start again in between.
Thanks for your help guys!
Quick overview: I develop Excel Macros for a firm. The Macros are used in a daily basis for more than 200 workers. These 200 workers connect the Local Machine to a common server (there actually 3 servers) and run the Macros from there.
Problem: Today in the morning some of these Macros (different Macros) starting crashing Excel with the tipical message "Excel has stopped working". These Macros (which I didn't update) run every day without a problem. Today, just like magic, they starting crashing for different lines of code which only common denominator is that they use a lot of resources.
Ex:
sh.UsedRange.Value = sh.UsedRange.Value (the UseRange is alcually a pretty small range)
Application.Calculate
wb.Sheet1.Move
I understand these are functions that take a lot of memory but still they have been working for months without a problem until today. I know this could be more like IT kind of problem but since I'm trying to solve this issue, I thought maybe one of you either had this problem before or know a possible cause (like a Windows update).
IT already reinstalled Excel in all the servers that we use for remote connection but the problem persists.
Any Idea?
Thanks a lot,
Ok, here is what happened in case you guys see this problem in the future:
Everything is Microsoft fault's. They launched an update to fix some Excel bugs and instead of fixing them, the server that automatic updated their versions, got really messed up. This updated was launched on Mar/14/2017 (2 days Ago).
I made some research and this sounded very weird to me. They launched an update to fix Excel 2010 bugs and now my Macros are breaking without changing the code? It had to be that and there it was.
Here's the Log:
https://support.microsoft.com/en-us/help/3178690/ms17-014-description-of-the-security-update-for-excel-2010-march-14-20
Just keep your head up if you have Automatic Updates on in your computer and see problems like these happening. In case you find that's the problem, just remove the update from your Excel.
Regards,
I am currently running into a similar issue with an Excel VB script utilizing the Today() function. The script freezes up and becomes unresponsive when the date is 03/17/17, but if I change the system date to 03/16/17, everything works great.
It appears that there were a number of Microsoft Office Updates on 03/16/17, so I am going to try and remove them one by one and see if that fixes the issue. I'm starting out with the Security Update for excel, KB3178690.
Update -- confirmed, removing Microsoft Security Update for Excel KB3178690 fixes the crashing issue related to the date function after 3/17/17. Probably some deeper reason to this, such as activeX forms or something (of which I don't believe this script utilizes), but at any rate it's working now.
My laptop ran the latest windows 7 updates last night and since then all my macros have stopped working. I have had to roll my laptop back to a point before last nights updates and everything is now working fine again. Think there is a major issue with the latest Microsoft update releases.
I'm kind of new to Visual Studio. I've built a few simple programs in it, but now I'm in the process of rewriting a huge system I wrote in VBA. What is frustrating me is the Error List in VS is only listing errors for one .vb File in my project, lets call that VBFile1. Now, when I work on another vb File, VBFile2, which is in the same project as VBFile1 no red squiggles or errors are listed for VBFile2. I don't understand how this could happen. This is what I've tried/checked:
Filter is set to 'Current Project' and I played around with the other Filter settings but no change.
Checked the Text Editor under Options and according to the research that I've already done it is fine. Plus, I have never changed any of these settings anyway.
Closed and re-opened Visual Studio.
Closed all open files in the Project and still displays the same error list
Close all files except the VBFile2 but still shows the same error list of VBFile1.
I have Visual Studio 2012 Ultimate. I feel like this should be an easy fix...I just am really confused what's going on.
Hope this makes sense!
UPDATE: Excluded from project, VBFile1 and finally errors are listed for VBFile2...why would this be?
I am not sure if it has been fixed in Visual Studio 2012, but there is a Connect Request for Visual Studio 2010 with a resolution of won't fix because of performance issues. The effect your are seeing is because you have exceeded the maximum number of errors for that project (what I am used to seeing is 102 as the threshold), it will not show you anymore till you fix the ones that it has already shown you.
According to this MSDN article, which I found through this SO question the limitation is still there for the IDE but has been removed for the command line compiler.
From above MSDN Link:
Limitless (Command-line) Errors!
This is actually a good thing, let me explain. For performance reasons, the Visual Basic IDE maxes out at 101 errors (with error #102 being “Maximum number of errors exceeded.”) This can make it difficult to estimate the amount of work remaining in certain situations, particularly in upgrade scenarios. We have removed this limit from the command-line compiler in this release, though it still there in the IDE. What this means is if you want to know exactly how many errors there are for a project, just invoke the compiler through msbuild.exe or vbc.exe and you’ll get your answer.
This problem is pretty self explanatory. Here are the details: I'm trying to include freeglut and glew in Visual Studio 2012 on Windows 8. I'm on a 64 bit system, so I thought I needed to put glew32.dll in my 64 bit system folder. I tried that and receive the following error:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
Which I've interpreted as I'm trying to put a 32 bit dll in the 64 bit folder or vice-versa.
Just for laughs, I tried putting the file in System32, but of course, it just told me the file wasn't on my computer. Any suggestions?
EDIT* May I also add that some of the set up for this was NOT the same as it would have been on Windows 7 or Visual Studio 2010 or earlier. I may have missed something because I kind of winged it using the search function combined with some documentation I found on various websites. (i.e the lib and include folders are no longer in the same place)
EDIT2* I'm sure this can probably be derived, but I want to add it anyway for clarity: If I removed the dependency for glew32.lib and comment out any code using glew.h, the window forms as it should. I don't think my source code is needed seeing as I'm 99% sure this is not a code issue, but if anyone wants to see it, let me know and I'll attach it.
I was recently reading an article on the Windows Metafile vulnerability (http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability#Third-party_patch) and I was interested by one of the points made.
A third party patch[9] was released by Ilfak Guilfanov on 31 December 2005 to temporarily disable the vulnerable function call in gdi32.dll.
So this got me thinking as to how Ilfak Guilfanov actually went about disabling the function in gdi32.dll.
My theory got as far as opening dependency walker and finding the function entry point and then analysing that in a Hex editor, however Hex isn't my native language unfortunately.
So would you require some form of expensive software to achieve something like this or would it be a case of a lot of trial and error ?
Note: This isn't intended as a hacking question, but more to understand what I see as a very interesting and clever process
You could open up the dll with your favorite (dis)assembler, find the entrypoint of the function and put a ret assembler instruction to directly return from the function without doing anything else.