I'm mostly new to programming and so I have come here for some help.
Recently, at work, the program that we have used for years has drastically changed and all of our old file types are no longer supported. This has left us completely out in the cold as to how we can access our old files without using the older software. With that being said, here is my problem with macros that I'm in need of help:
I need to be able to open a file in a specific program, copy all the text in the file, paste the text into a new notepad document and then save the notepad file with file's original name as a simple text document. I need to do this to an entire folder (and eventually folders within a folder but that can wait for now)
If I need to clarify anything let me know. Like I said, I'm new to this stuff and I'd appreciate any tips you guys could give me.
Since you mention Notepad, I'll assume that you are working in Windows. In that case, you're probably best off writing it in PowerScript. I don't have the skills for that, but if you add "Windows" and "PowerScript" to the tags, you may have a better chance of find someone sho does. (You may want to try this question over at SuperUser)
Related
In VS Code I have a tab with a plain text file I use for scratch while working during the day. I place all kinds code, questions, TODO lists, etc in this file and will reference it from time to time. It's helpful for history purposes.
At any rate, this file has ballooned up to well over 46,000 lines over the years and I'm now seeing this odd phantom line being injected at my cursor. I am unable to select it or remove it. I thought it was being displayed as VS Codes way of letting me know that a software update was available but when checking that was not the case. This is what it phantom line looks like, it seems to contain a history of CSS classes used over the years which is odd.
If I restart VS Code it goes away for a little while but then reappears. I have a feeling it might be because of the number of lines or perhaps memory but can't say for certain.
Has anyone else seen this behavior? I've probably enabled some setting by mistake and have no idea how to disable it.
Any suggestions would be greatly appreciated. Thank you!
Turns out it was the HTML End Tag Labels plugin that was trying to auto complete some HTML that was somewhere within the 46k lines.
I would have thought by identifying the file as type Plain Text, the plug-in would ignore trying to close HTML tags (since its not an HTML file) but alas that's not the case.
Thank you Mark Ahrens for the tip!
I know this is too strange question, but we have multiple authors of one document and some contributors use OpenOffice to edit document, originating and edited by majority in MS word. Document is quite complex with differently structured paragraphs and fonts, bullets, numbering, embedded pictures, references to comments under the line, copied/pasted sections pasted with source formatting instead of pure text etc., so generally "fragile" and maybe little bit exceeding expectations of OpenOffice authors for MS compatibility. Bottom line is about various formatting issues, glue-ing of some words (occasionally space is missing), page footer/header modified or completely disappeared etc. We are unable to control behaviour of contributors and editors to the extent I would like to have, so I am trying to findout whether is there a way how to force users to use exclusively MS word for particular docx and to prevent using anything else? (I am not on MS payroll, I personally moved couple of people around me with "standard" document writing needs to OpenOffice, but incompatibility in this case creates useless redaction work for us.)
Thanks for any hint.
whether is there a way how to force users to use exclusively MS word for particular docx and to prevent using anything else
To me, it sounds like a terrible idea to try to enforce this with a macro or similar (and it probably wouldn't work even if you tried). Instead, come up with a better workflow and communicate with anyone who may be involved so they know what to do.
First question, is the document under configuration control? For example, if a bad change is made, do you have a way of going back to a previous version? There are many different configuration management tools available, both free and commercial.
Next, I would strongly recommend making final changes with only one Office suite. Pick either LibreOffice (or Apache OpenOffice - is that what you mean by OpenOffice? The OpenOffice.org suite was forked several years ago) or MS Word to be the official editing tool, but not both.
If you pick MS Word, then people can still make preliminary changes to the document using LibreOffice. However, someone with MS Word will then need to use a Diff tool to see the changes and then use MS Word to incorporate those changes into the document. Or ideally, Track Changes would be turned on to make it easier to see what changes were made and who made them. Comments can also be added to explain why changes were made.
What is even better is to get people to send marked-up PDF files that contain their proposed changes. PDF files cannot be edited, which is good because it avoids the kinds of problems that led you to write this question, and also the formatting changes they made will not appear differently on another computer. However, this requires a certain amount of education so that everyone agrees to do it this way, and in my experience, that's not easy with a diverse group.
If you ever see that someone has made changes to the main document using LibreOffice, you or someone else needs to go back to the latest version not edited by LibreOffice and then use MS Word to incorporate all of the new changes.
At this point, if both suites have been used to edit the document, then I would probably start off with a new blank document and copy all of the text unformatted into it. This would require redoing all tables and other formatting. Otherwise, it's likely to be nearly impossible to get a clean document, and the underlying formatting may have no end to the number of problems that keep popping up.
I collaborate with other researchers and frequently have the following work flow:
I write a draft in Emacs org, then export it to docx.
Other authors make edits using track changes and add comments.
I revise the draft in emacs org.
For step 3, I import back the docx file manually, which typically involves:
- Accepting all track changes.
- C&P'ing text back into the org file, making sure that I do not delete markups (pandoc can help here).
- Putting the comments in a list and making todos and further edits; often I write down a note about what I did to address the comment.
I've been looking for ways to make this process better. I found other discussions of this issue, and it boils down to: if you can, have your collaborators edit the manuscript as a text file (not realistic for me, at list not at this point); or do some manual import similar to the one I described above.
So this post is about your thoughts / ideas regarding a great solution to importing back edited docx files that might become reality in the future, and how it could be done.
I think there are two parts here:
How to automatically import back text without destroying markups such as footnotes, references etc.?
How to automatically extract all the notes and integrate them into the Emacs org file?
For the second question, my vision would be to have some sort of comment blocks above the paragraph of the comment, or a list of headlines, each of them representing a comment and a link to the paragraph. A properties drawer would be a great additional feature, it could have one entry for open/closed and one entry for response / notes.
P.S.: I think this is a real barrier to using text-based manuscript writing and it would be a huge step forward if there was a good way. Even more, with all the capabilities of Emacs org, I bet the end result would be much better then revising a paper within word, which is just painful.
Here's how you might be able to do it
assume all changes are properly marked.
assume you know the "base version" of your org file.
assume every marked change comes with a "before" and an "after".
Then, analyze the .docx (same for .odt) looking for marked changes. Ignore everything else. Take the "before" version of each change, turn it into plain text, and try to find the matching element in the org file, then replace that text with the "after" version.
For comments, you could probably try a similar approach.
Caveat: I have no idea how easy/hard it is to find the marked changes, extract the "before/after" info and turn it into plain text.
Oh, and this will probably only work acceptably for small localized changes, e.g. the kind of thing you might get from a reviewer. For things coming from another author who may end up making larger changes and reorganizations it'll probably break down miserably.
I am working in matlab gui GUIDE and I am trying to rename a file. I open the fig file in GUIDE and save it as the new file name but a new .m file is NOT created. Consequently I cannot run the gui or edit the file. I have seen a lot of posts about this and many people say "Save As" should just work which is strange because it was working for me yesterday too. Does anyone know the reason why sometimes GUIDE does not automatically generate an m file?
The two files MUST have the same name. See the documentation here: http://www.mathworks.com/help/matlab/creating_guis/files-generated-by-guide.html
Further more, I can't find specific examples in the documentation, but there seems to be a common issue with Callbacks and UI property names getting a little messed up. The best bet is of course is to not touch the file names (or create the GUI programmatically) but now that the damage is done, I would reccommend:
Making sure both files have the same name
Checking all button callbacks to make sure they point to the right file
Checking the tag of all your graphics objects to make sure they are the sames
Double check in your GUIDE options that it is still set to generate an mfile ( Tools > Gui options > Create m file )
Best of luck, GUIDE can be good, but is very far from perfect. (especially in times like now)
Does anyone know of a software or system for automatically tracking and logging exact line code changes into a log file?
For example, lets say I edit 7 files on Jan 16th, and I add and modify several lines of code in each file.
Is there a software or tool of any kind that would automagically know what edits I made, what was changed, and log the details in date order line-item file?
I am guessing something exists like this, but I cannot find out what I should be searching for. I looked at SVN and some other similar, but didn't get these capabilities from the descriptions I read.
There's nothing that would automagically know this. This sort of information is easy to come by as a side-effect of using virtually any version control system though. It sounds like you're not using any VCS, you should start doing so now. SVN is a good option to start with.