Here is my problem for the winform rich textbox, a program receive message from car parking hardware by TCP/IP and I display the Events in the winform richtextbox by
richtextbox.AppendText()
everything are working well except the program freeze within a day or two
Is there a better way to hand this?
Write to log file and bind it to the rich textbox?
This has been asked before.
Things to consider: Memory limits, HD (file size) and RAM (display)
If you want to implement this with WinForms and not use some existing logging code I think a ListView and a random access file of a fixed size with datetime and limited log string as a ring buffer would do. Or use e.g. SQLite (delete entries older than today - TimeSpan, insert new) and use a DataGridView (ideally derived and double buffered for smooth scrolling)..
Related
I'm new to C# and WinForms, and i'm developing an application, which would allow me to read data from serial port and display it on some display tool (listview,...).
Now, i got serial communication and other functionalities working, but i'm having a problem with displaying the data. I need to be able to display incoming data really fast (every 1ms). To display data (for now), i'm using dataGridView, but the problem is that dataGridView is not fast enough.
So my question is: Is there some way to display data that fast? I know the human eye can't really see data in this interval, but still... It would be prefered to display data in dataGridView-like display, since it's really easy to organize data.
Best regards,
Nejc
You are not going to succeed displaying data every 1 ms. What you should do is buffer the incoming data on one thread, then every N incoming data, call on a method to display the data (i.e. you will be adding N rows at a time). Note you will need to use Invoke() as you will be calling on the GUI from a different thread (the thread that receives the data, not the thread that created the GUI).
I have a program running fine but when it hit nearly 10,000 images in WPF form thrown exception System.ComponentModel.Win32Exception: The operation completed successfully.
it so weird, sounds poor design, but functioning well as per the requirements. Without splitting process in to multiple, is there any better way that helps in getting rid of this issue and allow users to process over 10,000 images (controls in form).
I have double checked unmanged code disposed properly and used using blocks etc..
Background : Application creates image thumbnails of PDF pages and the images are stored in cache. Application is working well in handling a big load in giga bytes though it takes fair bit of time to create images on screen .(this is an acceptable delay)
It sounds like you have reached the Windows limit of 10,000 user handles.
You might want to try batching up the processing, or maybe using a virtualizing panel like the VirtualizingStackPanel to display the images. This will only create UI controls as they are scrolled into view.
I am writing an application that will display serial/USB data at a rate of up to 250kb/sec. I am using the .net SerialPort class and reacting to the DataReceived event. For early implementations of this software, I simply stored the incoming data in a WinForms RichTextBox. This solution works fine until there are 50k - 100k lines in the control, at which point the application bogs down. Since then, I've tried accomplishing my goals with WPF and found the same problem. I tried, at one point, to keep only the currently visible text in the textbox, and store the rest in a large List<string> but this solution required a huge number of workarounds and, in the end, was abandoned - I'd rather not reinvent the wheel.
Now I come to you for a thread of hope - I am willing to try anything! Should I use a custom control (both pay and free controls are welcome)? SQLite? Virtualization as described above? Should I try polling the SerialPort instead of reacting to events?
Use a thread to read the data and write it directly to a file. Have your app refresh the last x number of lines from the file every so often. Maybe even have the refresh based off of a notification from the reader thread?
By using multiple threads you'll keep the UI responsive and by writing straight to a file you'll ensure you've collected all of the data. Also, it will allow you to pause the display long enough to actually copy/paste the data you want while continuing to capture data.
Possibly you could implement your own type of file reader that would allow the user to "scroll" through the file by only loading the parts you can actually display on screen at one time.
If the data is largely line oriented (ReadLine) then put it in a ListBox. It is the fastest control for putting lots of text onscreen.
But you will find that all UI controls are geared toward human interaction, not to the speed of a Port. Best thing to do would be to rethink your design. What is that data for anyway?
I'm looking for a way to embed a cmd "Shell" into a Form. I want to build a C# based application that acts as a Terminal, better than the Powershell window (no tabs) or cmd (no nothing). Just start these interpreters in the backend.
I guess MS never thought of doing this. Any ideas what From elements I could use?
Thanks,
i/o
That's not a trivial task you're undertaking. I know of one project (Console2) which basically polls the screen buffer of the underlying console window and displays in its own. You certainly will have trouble coping with interactive applications like Far and the like as they (a) rely on getting keyboard events and (b) on manipulating their screen buffer. Both are icky things if you want a suitable wrapper around the console window functionality. Mouse input is possible as well (unless Quick Edit mode is enabled) which could give you further headaches.
I doubt you can use a ready-made control for this. Basically you need to display a grid of cells each of which has a foreground and background color. You could probably use a RichTextBox for this but I'd guess it's far from ideal.
Also I don't think no one at MS ever thought of this. It's just that there's a limited budget for new features and every one of them needs to be specified, implemented, tested, tested more for regressions with millions of applications out there, etc. It's just a freaking expensive thing (if you don't want to misuse your customers as testers, which they aren't).
It would propably be the easiest to extend the Textbox class and add logic so that it behaves like a console (respond to the KeyPressed/KeyUp/KeyDown events or similar). You can also add events for those things that your console needs to respond to. For example, add a CommandEntered event.
Basing your new console on a TextBox gives you the editing and display features of the textbox "for free", so you do not need to re-implement that.
You could use a richtext box, and set the background to black and foreground to white. RTB instead of text box to handle larger amounts of data.
You would have to write an awful lot of code to simulate the terminal though.
I've created a Windows CE 5.0 application which runs on a handheld scanner. The scanner has its own (hardware) keypad and almost all input comes from the scanning unit.
Unfortunately whenever the text box receiving the scanned characters is focused the input panel appears at the bottom of the screen, blocking almost a third of the screen space.
Is it possible to deactivate it in my form or in the whole application?
If you're not doing it manually via the InputPanel control, then I assume you have aygshell in the image and they are being rendered with a WC_SIPPREF control. I'm not certain if you can remove that control manually - I've never tried. There may be an agshell function that will allow you to disable/remove it, or maybe some work with the InputPanel for your app can remove it.
You may also want to see this blog entry for a bit more detail.
That last time I worked with CE was back when it was called pocketpc 2002 (I still have my old iPaq 3870 - one of the first devices with bluetooth and one of the last without wifi), but at that time the simplest way around this was to set the device to use a hand-writing recognition mode that didn't pop up anything. That may or may not be an option for you and things may have improved since then.