I am using Visual Studio Code on my Ubuntu box and when I checked in my code into BitBucket, somehow they are in different alignment, see below.
What would have caused this and how to I rectify this?
Your code almost certainly contains both tabs and spaces for indentation.
When this happens, almost any difference in how tabs are rendered will lead to anomalies such as you've shown above--code that looks right in one rendering looks all wrong in another.
Most code editors include ways to convert the entire file to using either spaces or tabs, but not a combination of the two. Using only spaces probably does the most to guarantee that the code will look the same, regardless of the environment.
On the other hand, using only tabs means that each user will probably see the code as s/he normally views code (at least assuming s/he has his/her environment set up to deal with tabs). For example, if the code is indented with tabs, and you like indentation to be by 8 spaces, but I prefer 4 spaces, each of us can get exactly that from identical source code (i.e., most editors will let us set the tab stops as we see fit).
Select the whole document or the line you have problem with,
Then go to Edit -> Advanced -> Tabify Selected Lines
That should fixed the issue. More info : https://blogs.msdn.microsoft.com/zainnab/2010/03/14/how-to-convert-tabs-to-spaces-and-vice-versa/
Related
we have a new set of labels generated with Zebra-printers. For the new labels, I use extensive character replacements in the ^CIx,... command.
(Most silly one I actually need is this: ^CI6,91,91,92,92,93,93,123,123,124,124,125,125)
For the new labels, everything works just fine.
But when I want to print some of the old labels, things get a little mixed up.
First of all, the old labels don't use any ^CI command, so I assume they were printing in ^CI0 (back in the times before the new labels came in). I don't know, though.
The best way, whatsoever, would be to just revert all ^CI settings to power-on state (but not reverting any other printer-settings).
I have read about ~JR command, but it goes a few steps too far for what I want to do.
Does anyone know a way to just reset the ^CI configuration?
Thanks in advance!
Regards,
Pelle.
If you can change the old labels, you should just add a ^CI0 at the beginning. From the Zebra Programming Guide:
We recommend that a ^CI command (or Unicode BOM) is included at the beginning of each
ZPL script. This is important when ZPL scripts with different encodings are being sent to a
single printer.
If you can't alter the old labels, you can send a separate (empty) label to the printer prior to printing old labels:
^XA^CI0^XZ
Printing code with Notepad++ is very handy because of the syntax-highlighting.
Unfortunately I'm experiencing a problem with printing.
Now at the left top of the page $(FULL_CURRENT_PATH) is printed, which is, D:\cppWorkspace\project1\display\GUI\main.cpp
I don't want the whole path, to the project, to be printed. However it also should not only print the file name.
In this case it should be, display\GUI\main.cpp. (which are packages inside the project and the file itself)
I tried to edit or set a Notepad++ variable, but I couldn't find a way to do this.
Hopefully someone knows how this can be fixed.
Thanks in advance,
Dennis
Unfortunately the variables are fixed, and cannot be "set" - at least as of the current version (6.3.1). They are simple replacements, handled in the expandNppEnvironmentStrs method in RunDlg.cpp
You're welcome to suggest an idea on IdeaTorrent (see the hosted apps menu on the Sourceforge project), or vote a similar idea up if one exists.
Currently, if there is ANY KIND OF ERROR in a view or route in nopcommerce MVC, I get alien unicode text, meaning it looks like you are viewing binary output via text. I had to rewrite this question because it was said to not be specific enough although this is just another way to say the exact same thing so not sure what to do.
This issue is fixed in version 2.30. Or simply apply changeset d21c5993c77f and dd416ab78db1. Let me know if it helped
My idea is that it's much easier to edit related code when it sits in single "work" file. E.g. in Rails application when you implementing some functionality you may edit 1 function per file in the following files: integration test, controller test, controller, model, controller helper. So if it would be possible to 1) mark this code fragments 2) automatically collect them in "work" file 3) edit them togather 4) the tool synchronizes (puts back) the changes; it could simplify development process in many cases. Especially if you need to go through many tweek-and-try iterations.
Vim works fine for this. Install the Rails.vim(1) plugin and with the command :AV you can open a vertical split with the accompanied tests/specs, or :RV to open related files like migrations and views (depending on whether you're viewing model or controller). When you're workspace becomes to cluttered, use :only to go back to one file. Splits are the best way to manage multiple related files IMHO. You can even open the same file twice to see two parts of the same file. It's not exactly the same as you are describing, but it comes close.
1: http://rails.vim.tpope.net/
Just open up Vim and open some windows. What's the problem?
I have a question regarding template parts. I want to create a control that inherits from ChildWindow, but I don't want it to have a border, OK/Close buttons, etc.
Is it an acceptable practice to remove the template parts that I don't want? I have created a copy of the ChildWindow template in Blend and removed the template parts, and it works fine - I just want to make sure that that won't cause any problems down the road.
Thanks,
Charles
If you read some of the custom control development documentation on MSDN it specifically mentions that developers should anticipate that template parts may not exist and code for it, so I think you're Ok there. Personally, when I need to remove template parts I prefer to leave them in the Xaml but set Visibility = Collapsed for something like a button or BorderWidth = 0 for something like a Border. Personal preference I suppose.