I am writing a simple application that should implement the TELNET protocol.
I got to the point where I have to implement the console-like text behaviour. I need the following:
Something that prints out the message from the remote host (Different options available)
Something that gets my message to the remote host (Doable with an external text field)
What I am trying to achieve is a single text view/field that prints the output, gets my input in the same view, and doesn't let me edit the previously printed text (just like a regular terminal window)
I tried with a (scrollable)TextView, tweaking the isEditable field on and off, but it does not appear to be what I am looking for.
This is what appears to the user once the connection is established
This is what happens when the user press backspace.
I would also like to prevent the editing of all the text written before the last return key.
Am I checking out the correct container? Is there something more suitable for my need?
Related
When you try to automatically enter the desired content (and there will be a lot of such objects with text content and I would prefer to avoid entering all the necessary data manually), the input field moves from the console to the area highlighted with a red rectangle, which makes it impossible to automatically create signatures.
The question is, is it possible to make the input field of the desired content always remain on the command line?
enter image description here
I tried to find the question on the Internet by entering the corresponding queries in Russian, nothing gave results
I understand that by "automatically" you mean copying and pasting from some editor to the AutoCAD command prompt.
I will never work that way, you must use a programming language and I think the easiest thing is to use AutoLISP.
Try copying and pasting this:
(command "_mtext" "36,0" "42,0" "your text here" "")
and note the empty string at the end "" that finalises the MTEXT command.
The "~JA" command, as stated in ZPL Programming Guide vol.2, cancels all commands in the buffer.
We were using the ~JA at the start of every PRN file and it worked as intended on ZM400 and ZE500 models. The goal is to have only one printout in case multiple prints are triggered. So if I press "Print" 3 times, only the third label prints out.
I have tried:
- introducing the ~JA command through Zebra Designer interface
- introducing the ~JA manually in the PRN at the start of the PRN file as ~JA~; ~~JA~; ~JA
No luck. On the ZT410 nothing prints out, the printer just hangs there with the data led blinking.
Any ideas?
This is the kind of question that wants a higher level control at a lower level. If you only want 1 label to be printed after a button or print dialog is initiated, it needs to be done at a higher level than ZPL II. Sending a ~JA command typically just flushes the command buffer on a printer less than it does eliminate the ZPL that is being sent before it. In your case, you should eliminate the user's ability to hit the print button 3 times. Effectively adding a de bounce function to your higher level program. It is good however to send a flush command before sending the ZPL you want to print, in case a cached command for a label is stuck in the buffer for the printer. There have been instances where an old label will print out because I have neglected to send this command at the header of my ZPL generator.
I am in the process of creating a system that can print labels. The designs have been created in Label Matrix, but I need the ZPL (Zebra Programming Language). Does anyone know if I can go from Label Matrix to ZPL?
Thank you very much
You can add a new ZebraDesigner ZPL driver to the system and use a file as the port. Then when you "Print" the document, it will write the ZPL code to the file.
Note that it might have some header information before the first ^XA which you might not need.
Also, how to add a local port for a driver:
Go to Printer Properties
Click on the Ports tab
Click Add Port
Select Local Port and click New port
Enter a filename e.g. C:\output.zpl
Make sure it is checked in the ports list
Now all printing output should go to C:\output.zpl
Alternatively, can just click Print, tick "Print to file" checkbox, output to a *.prn file, open that file with Notepad and the code is there.
I am trying to create a program which will have live updates from some data source. And I also want to wait for user input just like a normal terminal. Right now, whenever there is update, I will print the content and print the prompt message for input again which create something like this:
Enter command >
This is a live update message
Enter command >
This is a multi-line li......
......ve update message
Enter command > quit
Bye bye!
The problem is that for every live message I received, I will print it and the "Enter command >" will be displayed again again and again, which is not desired. I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
The closest package I can found on Github is https://github.com/gizak/termui but most of the examples inside is trying to display text, gauge and graphs. So I am not quite sure how to get started.
Is there any package or example of the termui package to achieve this? Thank you.
With github.com/gizak/termui you're heading in the correct direction.
To understand why you can't get that
I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
part sorted out, a little excursion to the history of computing is due. ;-)
The thing is, the mode your teminal emulator¹ works by default originated
in how computers would communicate to the operator in the era which predated
alphanumeric displays — they would print their responses using a line printer. Now think of it: a line printer works like this: it prints whatever is sent to it on a roll of paper. What was output, was output.
The new output always appears physically below the older.
When alphanumeric displays (screens) came into existence they
naturally continued to support this mode:
the line text to be output was rendered at the bottom of the screen
with the text above it scrolled upwards.
That's what you see in your typical terminal emulator all the time when you're working in the command line of a shell (such as bash) running by the emulator window.
This, default, work mode of a terminal is called "canonical" or "cooked".
Then came more advanced displays, for which it was possible to change
individual positions on the screen — identified by their column and
row numbers.
This changed the paradigm of how the information was output: the concept
of a so-called "full-screen application" was born.
Typical examples of them are text editors such as Vim and Emacs.
To support full-screen text output, terminals (and terminal emulators)
were adapted by implementing certain extensions to their protocols.
A full-screen application first requests the terminal to switch into another
mode called "raw", in which the terminal sends most of what is input by the
user directly to the program running on the terminal.
The program handles this input and orders the terminal where and what
to draw.
You can read this good summary
of the distinction between the both modes.
As you are supposedly suspecting by now, to be able to keep some block
of information at a certain fixed place of the terminal's text screen,
you want your program to be a full-screen program and use the terminal's
raw mode and its special commands allowing you to directly modify
text at certain character cells.
Now the problem is that different terminals (and terminal emulators)
have different commands to do that, so there exist libraries to isolate
the programs from these gory details. They rely on the special "terminal
information databases" to figure out what capabilities a terminal has
and how to make it do what the program asks.
See man terminfo for more background.
The most widely known such library (written in C) is called ncurses,
and there exist native solutions for Go with supposedly the most visible
one being github.com/nsf/termbox-go.
The github.com/gizak/termui makes use of termbox-go but for you it might
suffice to use the latter directly.
¹ Chances are very high you're not sitting at
a real hardware terminal
connected to a UNIX® machine but are rather working in a GUI application
such as GNOME Terminal or xterm or Termial.app etc.
These are not "terminals" per se but are rather
terminal emulators —
that is, pieces of software emulating a hardware terminal.
This is a GUI application (actually MFC). I need a command window with the ability to display a prompt like such:
Name of favorite porn star:
The user should be able to enter text after the prompt like such:
Name of favorite porn star: Raven Riley
But I need to prevent the user from moving the cursor into the prompt area. Users should also be prevented from backspacing into the prompt in order to prevent the following:
Rrraven Rrrileeey Ruuuulez!!! Name of favorite porn star:
Also need to control text selection and so on. And finally, I should have no problem retrieving only the text the user entered (minus prompt text).
Will it be better to create my own window class from scratch (i.e inherit from CWnd) or should I reuse the Windows EDIT control (i.e. inherit from CEdit)?
A similar command window can be seen in AutoCAD and Visual Studio (in debug mode).
I think you'd be better off creating a subclass of CEdit and limiting filtering key-presses. I suppose the hard part is not letting the user move the caret to the prompt area, but you can probably write some code to make sure the caret always get sent back to where it belongs (the input part).
Anyway, if you really, really want to implement your own control (it's not that difficult after all) I recommend you read Jacob Navia's "technical documentation" on how he built the LCC compiler and environment. Actually, it seems the docs are not online anymore, but I'm sure you can get them through his e-mail (jacob#jacob.remcomp.fr).
Edit: I liked your previous example better. Keep it classy, LOL :)
I had a very similar requirement and did exactly what davidg suggested; subclassed a edit control and filtered key presses. This was actually using Qt not MFC but the principle will be exactly the same.
You need to remember to filter keys such as home as well as left and backspace. I just checked to see if the move would move the caret into the prompt and if it did ignored the keypress.
Another thing to watch for is pasting multiline text, you will have to choose whether to just paste the first line or all lines, adding the prompt on all lines after the first. When subclassing the control you get lots of behaviour which won't work exactly as you want it.