Searching and Replacing in CUIX File???

[johnw]

I currently have paths set in numerous macros within the CUIX file. Is there a way to search for certain text within the CUIX file and replace it with something else. E.g. I want to change all my "Z:/...." callouts to "C:/..."

I have A LOT to revise and hope there's a way where I don't have to go to each command and manually update...

Any ideas would be appreciated.

Thanks,

John

[Ranjit_Singh]

Try something like this where you pass the path to the cuix file by a findfile or passing the actual path as string. Let's say the path is in variable x,

(setq file1 (open x "r")); pass the path to cuix as a variable x 
(while (setq a (read-line file1)) (setq b (append b (list a))))
)

 Now you have your entire cuix in the variable b. Make all the edit operations to variable b based on your path changes, etc. Finally, write back to the same cuix file

(setq file1 (open x "w")); pass the path to cuix as the same variable x 
(foreach y b
(write-line y file1 ))
(close file1)
(setq file1 ())
(gc)

Just be careful when you edit b to catch only what you need and not to change anything else. Make a backup of your cuix , just in case.

EDIT: Just realized that cuix is not a text filetype. The above maybe useless. How did you build your cuix in the first place? Did you use a text editor or through the CUI interface?

[johnw]

I did it through the CUI interface...

[Ranjit_Singh]

cuix can be unzipped using any zip archiver (wizip, WinRAR etc.) Unzip the file and then you can open each one using a text editor. Run the previous suggestions (of re-writing the files) on each of those files. Zip it back again and rename extension to cuix.

If this is a one time deal you can do the above. I don't see a reason why you have to keep changing paths constantly. But if you have to for some reason, I believe you can automate even the zipping and unzipping. WinRAR has a console version and you can call it through cmd prompt.

[JamesMaeding]

I'll be curious to hear if this works.

Be sure to delete the .mnr files for that menu, so it recompiles them on load.

I do see plenty of reasons you would change paths in a menu macro, and still recommend anyone doing menus not requiring a ribbon, to use .mnu format.

You can still menuload a .mnu, and edit in normal text editor to do pulldowns and toolbars.

I attached a .mnu of ours as an example.

Notice the .mnl file, which has the command HATMNU.

That will unload the menu, then reload the .mnu, so you can have the .mnu open in text editor, make changes, save, then type HATMNU to reload.

Now that is slick menu editing!

You can use .bmp files for images, or compile them to dll with free visual studio like I did.

[johnw]

I'm only changing the paths back to C: drive because the Z: drive is a flash drive and I want to get rid of the flash drive component when working remotely. So if I go back to C drive, then remote workers can easily load files and work anywhere. I don't plan on going back and forth.

[Ranjit_Singh]

unzipping will give you close to 20 files. So, I would still recommend to write a function to pass the unzipped directory and read all the file names and then call read-file and update-file for each of those files

(vl-directory-files x nil 1); pass the directory as x

. or use getfiled to pick a file and return the directory name

(vl-filename-directory (getfiled "" "" "" 0))

 then strcat the directory to each of the filenames and then call read-file and update-file.

If you do not want the hassle to do all the above then just use notepad to open each of the unzipped files and then find and replace.

[JamesMaeding]

I would say your approach is to your disadvantage, as you don't want tools to depend on paths to be found.

Instead, use support paths to control what gets found.

So you can add the z drive stuff at top, if you want it found first, and have c drive below, or whatever.

This is normal acad setup issues, and makes it so you can use the same menus and lisps anywhere.

I even have a folder for each user that goes near the top, above my lisp tool paths.

They can copy one of mine, put in that folder, and modify it.

That way I keep a company standard set of stuff, then the users can add to it or change by copying files.

I also use acaddoc.lsp to control support paths, but you don't have to do that.

I have not modified my menu paths for years, all my load statements let acad find things like (load "somelisp.lsp"), not

(load "c:\\tools\\hope this path never changes\\oops\\somelisp.lsp")

I support three versions of acad, and one of bricscad, I'd go nuts hardcoding paths.