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
Related
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/
Is it possible to use Acrobat.MenuItemExecute('Copy'); command with
AVDoc.OpenInWindowEx(FFilename, Panel1.handle, 0, True, 0,0, 2, 0, 0, 0);
in Delphi 7 and Acrobat XI Pro?
If you help me with an example I'll be glad.
I think the answer to this is probably "no" because before calling Acrobat.MenuItemExecute('Copy'), it is necessary to call BringToFront on the window containing the text you want to copy, otherwise the call to MenuItemExecute('Copy') will fail, even when the document is hosted in one of Acrobat's own windows. I don't see how you could do that successfully when the document window is hosted in your app, rather than Acrobat.
However, there are a few things you could add to your q that might assist in getting a better answer. [...]
Update Please disregard my comments in an earlier version of this answer saying that I could not reproduce the behaviour that I could not select text in the window opened using OpenInWindowEx. In fact, I can now select text fine, what I had overlooked previously is that I had set the Enabled property of my TPanel to False.
Unfortunately, I have still not been able to successfully call Acrobat.MenuItemExecute('Copy') and I am beginning to think that there is no way to do this in a hosted window. I have not found a definitive list, but various comments by Adobe staffers that google found make it clear that many MenuItemExecute strings just to not work when using OpenInWindowEx.
However that may not be the only way to retrieve the selected text back into the Delphi app.
If you look at the hosted window using a tool like WinSpy or Window Detective you will see that contained within the panel window is a whole host of Acrobat windows, including an AVL_AVView one with the Window text "AVPageView" which I imagine is the actual window displaying the PDF text.
I think the key to a possible solution is your observation, which I've confirmed, that pressing Ctrl-C in the window copies the text to the clipboard. So far I have not been able to achieve the equivalent in code, using techniques like keybd_event calls, various Delphi "SendKeys" routines and sending a WM_COPY message to the AVPageView window. I'm sure it must be possible, but I haven't yet found a way.
The employees of our company use gnome-terminal run from Debian workstations to access a variety of systems running different O/Ss on our local network. Everything works very well except that the host systems and their applications use different character sets, either ISO-8859-1 ("Latin 1") or UTF-8, and the server applications notably do NOT adapt to the locale of the user. This requires the user to manually set gnome-terminal's character set encoding each time one starts a new session!
(In case that's not clear, we always want to log into system X using ISO-8859-1, and always log into system Y using UTF-8. This has to do with the relative antiquity of the O/S of each system, the older ones having little or no accomodation of UTF-8 while the newer ones deal rather grumpily with ISO-8859-1.)
It seems to me that gnome-terminal's character set encoding should be associated with the system one's logging into instead of the system one's calling from. And that therefore, the character set should be one of the parameters that can be pre-set in the profile. This is the way other terminal emulators behave, notably the Windows and Mac emulators that we use outside the office.
But in lieu of configuring it in the profile (which is not possible), does anyone know a way of setting the character set encoding as part of a command line invocation of gnome-terminal?
I've been trying to solve this annoyance off-and-on for years... any solution would receive our eternal gratitude. :)
in the good old times, gnome-terminal support --disable-factory, you can set up for local editing files:
#!/bin/sh
export GDM_LANG="de_DE#euro"
export LANG="de_DE#euro"
export RC_LANG="de_DE#euro"
export LC_ALL="de_DE#euro"
gnome-terminal --disable-factory
or remote access to a linux-box:
#!/bin/sh
export GDM_LANG="de_DE#euro"
export LANG="de_DE#euro"
export RC_LANG="de_DE#euro"
export LC_ALL="de_DE#euro"
gnome-terminal --disable-factory --tab --title="Server1 DE" --command "ssh user#Server1"
Now at gnome 3.10 I get
... Option "--disable-factory" is no longer supported ...
So, I am with you and will keep looking ...
Mario
This worked for me.
LANG=en_US.iso885915 /usr/bin/gnome-terminal
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.
I'm trying to do a block selection using jVi in Netbeans. I cannot seem to get it working - there seems to be a lot of good info on this topic, however I'm not seeing the answer to my problem.
This is what I understand: to do a block select, you first enter visual mode and select some text. Then you hit Ctrl-V to enter block select mode? For me, Ctrl-V pastes the clipboard, so I found someone mentioned Ctrl-Q. I try that, but I cannot get text to select in a column using the arrow keys or the h,j,k,l keys. For me, it just does a regular selection grabbing the rest of the line, and the line below (if I move the cursor down) up to the cursor.
What am I missing?
jVi has options to specify which control keys are handled by jVi and which passed on to NetBeans for processing. Your description indicates that Ctrl-V is being handled by NB (not by jVi). In NetBeans look at
Tools > Options > jViConfig > Ctrl-Key Bindings
and enable/check the keys that jVi should process.
Make sure you're not in a special more before you start (just press ESC a few times). It's also possible that some of your jVi startup scripts are remapping those keys.
Ctrl-V is the default, but Ctrl-Q was introduces on gvim on Windows, to avoid confusing users who knew Ctrl-v is for pasting text. You can look at your key mappings by typing
:map
in command-mode. You can even do
:verbose map
to find out where each mapping was defined. I think that only lists user-set mappings, so it'll show you when Ctrl-V and Ctrl-Q were re-defined by a script.
This worked for me - combining both suggestions from above. In jVi settings page, enable Ctrl-Q and use it for classic Ctrl-V functionality. Do not enable Ctrl-V as it has too many side effects wrt handling of mouse selection buffer. Works nicely in this way for me with netbean 8.2.