conflict between editing and background updating of edit control

Hi everybody,

I'm developping an applicaton in C, (not C++!), using Visual Studio .NET, thats connecting to a machine via profibus. Its showing a dialog box with about 20 values in edit controls, as well as some check - and radio buttons. I need to solve 2 problems:

1. The values need to be shown asap, so i created a thread thats steadily reading and showing them. I too need to change them. Because updating is done by a thread, it conflicts with editing and sending. To solve this problem, I see 2 ways: 1. blocking the update to the control thats being edited 2. creating a popup , edit there and send it when closing. Any hints, please?

2. Are there any enhancements to edit control available that support input of floating point values, or do I have do do it all by myself?

I did years in developping drivers for applications on some special hardware, and just started programming Windows; so forgive me if these questions seem strange to you.

Do you gurus out there have other (better) ideas, especially for 1. ?
Examples are very welcome!

Thx in advance

Hi,
first I want to tell you, that you are probably in the wrong forum, because of Visual .NET.

Anyway, I don't have a readymade solution for you, but I had some nearly simmiliar problems in an application a long time ago.

Ok, let's see if I understand your prob right:

You have one or more editfields.
You update the contents in a thread in an intervall of n seconds.

If you, for example, type something into the edit, it is overwritten by the thread-routine.

The problem is, that your thread-routine uses a buffer, that is NOT the same as the internal edit-buffer (right ?) and with it's (old) content your newly edited text is overwritten.

--->

Is this a description for your problem ? If so:

I don't know which edit-control you use. Anyway, how about using the (internal) buffer of the edit-control in the thread also ? I think if you do so,
the thread will just write to the buffer what is allready inside (including newly typed chars).

What would be interesting is, where the data comes from, that your thread writes to the edit.

Maybe it might be a good idea to implement somewhat like a model-view-controller-paradigm in your software.

Therefore it might be a good idea to strictly modularize the tasks of data-processing (creation) and displaying data.

How about writing handler-methods that handle keypress-events for your edit(s). those handlers can work on the same data, your thread is processing and "keeping the thread informed" what went on in your edit.

--->

Ok, I'm not in this game right now, so I just can give you some vague tips about solutions.

Anyway, if this is a help to you... fine ;o)

If you have any further questions, or if I misunderstood you ... post it again sam ;o)

Greetinx

Juergen

Hi Juergen, thx for answering. I choose this forum because I'm programming in C, not C++; may be this was wrong, but anyway, now I'm here.

Let me try to clarify my problem.

There is a value in the machine, lets say 100 Volts. This can be changed by different resources, inside the machine, by pc or else; so it must be scanned quickly, meaning < 100 ms, because it may be neccessary to react (via program, of course). This scanning is done by the thread, which also displays the value (changed or not). So, the value shown in the edit control reflects the actual value in the machine. If I try to edit this value via keyboard, it will permanently be overwritten.

This problem doesn't occur with a check or radio button, because I can send this rightaway when its pressed. With numeric values, its different. Those values need to be edited and sent when editing is finished, f.e. by carriage return.

So in the moment I want to edit this value, I have either to stop the updating this control or use another control to edit it. What I don't want to do, is to use 2 edit controls for every value. Thats why I mentioned some kind of popup, but I don't quit know yet how to do this.
:confused:

I believe you should separate the control for editing and display. Since the display control is constantly updating, it is better left as read-only. If the control has dual purposes, it can be very confusing and also unusable. I perfer you idea of using a pop-up dialog for capturing input. It would also be better if you could decouple your data from the UI.

Just some wild thoughts, you may like to place a small button besides the read-only edit box. When you click on it, a dialog box pops up and prompts you for the new value. At the same time, you should set a flag or event to stop your thread from updating.

Just being curious about using a separate thread. Since you mentioned about different resources (may be some functions) updating the voltage value. Is it possible that these resources make a call to update the UI themselves thus avoid using multi-threading?

by diff resource I mean the machine itself or another station on the bus, not a function. I can't stop the thread, because the also integrated control modules would be blind. But, how these discussions work, you get other ideas. I redesigned my approach and decided that not all values are vital information, because they usually don't change. That leaves only about 5 values that need permanent update, and I keep those as readonly, providing a separate control for editing. Concerning the before metioned popups: do you have any examples? thanx for your comments.

Quote:

---

Originally posted by Wild Thing
Concerning the before metioned popups: do you have any examples? thanx for your comments.

---

An simple dialog box, with an edit control, a Ok-button and a Cancel-button, should be more than enough. You should be able to reuse the same dialog box class to capture inputs for all 5 fields.

Quote:

---

But, how these discussions work, you get other ideas

---

From the attached diagram, you can separate your data from the UI. By sharing the data among multiple resources, you may need to implement synchronization so that the data can be accessed by a resource at any one time. As for the UI, you can still keep a separate thread running to pull the latest data. In this way, you should not have the earier stated problem.

Hope this helps.

Sorry, forgotten the attachment.

yep, dialog box running, mission accomplished. Thx for your help.