So, I'm not sure whether this has happened to anyone else, but I'm using Rmarkdown to create a beamer presentation. For whatever reason, there are some .Rmd files that are compiling, while others constantly go into "extended mode".
For instance, if I create a brand new .Rmd file, it will compile, but if I copy the contents of the document into another file (same exact thing), it goes into extended mode looking for pgf. Any understanding of why this might be the case?
Figured out that the problem was being caused by the auxiliary and intermediate files that are created once you try to compile the document. If you delete them, this should be resolved.
Related
I am trying to define 2 custom filetypes that I want them to feature thumbnail previews within windows explorer and I used this code sample (https://code.msdn.microsoft.com/CppShellExtThumbnailHandler-32399b35) to register the new shell extension but I can only make one of them work at a time.
The moment I try to register the second one it seems it replaces the IThumbnailProvider's Handler Subkey {E357FCCD-A995-4576-B01F-234630154E96} and breaks the first filetype's registration. If anyone has some experience with this, my question is,
can I register more than 1 filetypes at a time using this code sample?
Is there an alternative?
Thank you!
I managed to register more than 1 custom files, but the way I did it leaves me baffled... So if anyone could take the time to explain it to me I d sure appreciate it.
I copied the c++ project/solution to a new folder, changed the custom filetype parameters inside the code to match my 2nd custom filetype needs, build this new project and registered the resulting .dll.
So basically, what made it work, is that when you build the project/ solution the files that are being produced (the .dll being just one of them) are essential for the thumbnail handler to work.
And this is what baffles me.
I would expect that after you register the .dll, the new filetype is established and that I could even get rid off the aforementioned files. But apparently not only you have to register the .dll, but also make sure you keep the other files that are being produced upon built, unchanged in everyway.
So that basically means, 1 project/solution per custom filetype, nicely saved in its own folder :)
Is this the right way to do this, or am I just hacking it here?
So I've been spending the last 2 days trying to inject a new section into a PE file, but unfortunuately, without much luck. I am able to dis-assemble, and then re-assemble the whole PE, but when I try to inject a new section, the file becomes corrupt. As soon as I try to launch the file, I get the useless error message "This program cannot be run.". I wanted to try and fix it myself, but I'm completely stuck. Here is my code, there are a couple of temporary hacks in there for debugging purposes, which I will get rid of later.
My code: http://pastebin.com/ZfZqUWUG
Sorry for the rather large file, but the problem is that I have no idea what I'm doing wrong. Any help is appriciated.
UPDATE
My goal is to write a packer which would allow me to secure exe files. I'd have a builder, which encrypts all the existing sections, adds a new executable section, and change the entry point to that section. The code in the new section would decrypt the other sections, and jump to the original entry point.
I can see the new .inj section with PE explorer, and it also displays the data "Test".
I wrote a lot of code in C++ and save. After that I want only try some example code which I find. So I paste this code in this my project main.cpp file (where I had my code). I try it example code and mistake close this file. After that I open main.cpp file, but I can't undo changes by Ctrl-Z. I wanted only try example code and then I wanted undo changes by Ctrl Z, but my mistake is close file. Is it possible undo changes after close file or restore it?
Your original code is probably gone for good. However, perhaps this is a good time for you to consider adding a version control system to your tool set, which will help you avoid this kind of mistake in future, as well as give you a lot of other benefits.
Also, it is not a wise idea to paste example code over your own work in the way that you've done, for exactly the reason you've discovered. Insert a new file into your project, or create a separate project for testing example code. I have a separate Visual Studio solution specifically for this purpose.
EDIT: I say "probably" because I can't rule out all possibility of recovery based on the information you've supplied (e.g. you might have some kind of scheduled backup which caught your previous version). Also, if the code you pasted over it was shorter than your original code, it's possible that some of it still exists as unused data blocks on your hard drive, and might be recoverable, assuming something else hasn't already overwritten them.
I have preferences file for my application in Qt.
Whenever I launch the application it loads the file & depending the contents creates the widgets accordingly. I have given some customisation option for the user. Now when my application is closed I am checking whether the preferences are changed. If yes then I am opening the preferences file again & then just adding everything again in it. I am not creating a temporary file, I am directly editing the file. Is this method an efficient one? or am I doing it wrong? because I found these threads:
1. What is the best way to edit the middle of an existing flat file?
http://qt-project.org/forums/viewthread/25924/
Should use I binary file? Currently I am using ASCII file.
Thanks.
UPDATE: In the stackoverflow link above the correct answer has
If you're stuck using flat, then you're stuck using the old fashioned
way of updating them
I meant to ask whether the method I am using is old fashioned & is there a better method used nowadays? & what does flat file mean?
Don't try to edit the file. Rewrite the whole thing
Rewrite by using a temporary file. i.e. write the current state of preferences into temp file. And then move/rename the file to your actual preference file after making sure the temp file has been written successfully. This helps in case there is a crash when you rewriting the file. If you rewrite it directly, you will be left with neither the old one nor a good new one. In case you do it through a temp file, then do it this way ensures that in case of a crash, you atleast have a good preferences file(though it contains the old preferences).
Text/Binary doesn't make much difference unless it's a really huge file. Text will help to hand edit it if required.
That's a perfectly fine way of doing it. Since you already seem to have all of the preferences loaded into memory and you have edited them there, you don't need to bother with a temporary file (unless you want to ensure safety if your program fails during writing). Just write all of the preferences back into the original file.
Whether you choose a binary file or text file is up to you. Preferences tend to be text files because they have the added benefit of being human readable with just a text editor, rather than some specialised software for viewing them. A binary file may, however, have slightly better performance due to simpler decoding.
I tried to write a program for safe deleting files. However, I have a problem with deleting system files (recycle bin etc.). Now my question is. Which way to hidden files (from users) at this dialog. Other files I add to listview and then rewrite them zeroes. After that I delete this files without recycle.
The only way guaranteed to do this is to write your own open file dialog. But I'd advise that you find a better way of doing this, since that's considered pretty bad form.
It just occurred to me, but what you could do (and I'm not saying it's easy or nice) is launch the open file dialog, then using the handle to the window gain access to the listbox, and manually remove any system files from that list per your own heuristics. It should work, but I can't guarantee that the items will remain removed (i.e. I think Windows will auto-refresh every so often), so you'll have to experiment and YMMV.
Bottom line: find a different way of preventing the user from selecting them. Like Mat says, perhaps just give a message and leave it at that. Failing that, write your own dialog (yuck!).