Firstly (as Lee's stated), never, ever, ever even consider touching any acad####.lsp or acaddoc####.lsp files. Those are from ADesk and could change at any update / upgrade, effectively erasing all your customization. You are allowed to create your own ACAD.LSP and ACADDOC.LSP files, as long as they are in a support folder, they'll get loaded. The ACAD.LSP is (usually depending on ACADLSPASDOC's setting) only loaded once per session, the ACADDOC.LSP is loaded for each DWG opened (always, no matter any other setting). Any MNL file named the same and in the same folder as the CUI / CUIx (even if that folder's not on the support list) will also get loaded for each DWG - always. That's why I like this method more - it allows for the least amount of setup: i.e. I simply need to load the CUI, no registry edits, no changes to the support paths, no modifying any other files.
If you want to make sure that your code runs, you can always add a princ call with a message like "My code's just completed successfully". That way you can see it on the command line.
The startup suite also loads for each DWG, but as stated some of the code may fail in any method of auto loading the LSP file(s) if you're using command calls. It won't "always" fail, it depends on how long it takes for the DWG's command line to become ready to accept commands. E.g. in a rather small 2D drawing there might not be a problem, but due to some extra libraries being loaded on a 3D drawing the command line takes longer to become ready - thus the same code which worked for the 1st DWG will not work for the 2nd. Note this is only if you use command or vl-cmdf, doing stuff with setvar and such won't be affected. So if you don't need to call command / vl-cmdf you also don't need to worry about S::Startup.
About S::Startup ... there usually isn't one at all. It's just a name that gets checked, and if it exists it's called as soon as the command line is ready. You can create it the usual way, but it's highly frowned upon if you make it a normal defun. The reason is it's used to settings for all addons. Thus each addon needs to be able to append to it without needing to modify existing files. E.g. if you install an addon, you don't want it to screw up your other addon's workings now would you?
For that reason you define it thus:- (defun-q S::Startup () ;; any normal lispcodes, but usually only command calls)
Although that way of defining it would overwrite any previous definitions. That's why you define a temporary defun-q and then append it to the S::Startup. That way any other addon's codes are still in the S::Startup as well as your own ... without you needing to modify the other addon's files at all. See my previous post.
You could place this code into any LSP file which gets loaded automatically. It will append to the S::Startup function and be called when the command line is ready - not before. The way your code shows is wrong for 2 reasons:
- It simply redefines the S::Startup, so any other addons also using it might break if their codes were added to the function before yours.
- You're using the normal defun which makes a "compiled" function instead of a defun-q list. Thus later calls to append to it would then fail ... i.e. other addons loading after yours will fail.
You can see on my previous post I'm trying to circumvent the 2nd problem: I check if S::Startup has been defined already AND if so that it is also a list. If both conditions are met I append my defun-q to the S::Startup. Otherwise it was either not defined yet, or some erroneous addon has defined it wrong ... therefore I overwrite it. Unfortunately there's no way of fixing the 1st problem without editing the erroneous code (which is sometimes inside an uneditable FAS / VLX file) or stopping it from loading. | 
置顶卡
