1

I come from a physics background so I have very little experience with MFC. However the Thorlabs stepper motor controller we are using talks to the PC through an ActiveX control.

I have written a little program that moves a motor, measures the signal at that point and then moves on in the process scanning a 2D area. However the UI locks up while the measurement is running. Is there any way to prevent this from happening? It would't be a proble aside from the fact that connections with the various devices should be properly closed which can be done with the "Proper quit" button if one could click it.

The UI looks something like this: The UI of the program at question

Jānis Šmits
  • 173
  • 1
  • 10
  • 2
    UI is executing in its own thread and you are locking that thread if you execute your (long running) code in response to a UI event (a button click?). You need to create another so-called [worker thread](https://en.wikipedia.org/wiki/Thread_pool) – mvidelgauz Aug 17 '16 at 16:34
  • 1
    Another approach is to perform you measurement in small steps and execute one step per [onIdle](https://msdn.microsoft.com/en-us/library/3e077sxt.aspx) – mvidelgauz Aug 17 '16 at 16:36
  • Thank you! I guess I will start with trying to make onIdle work. To be honest I had a hard time understanding the various tutorials on worker/UI threads. – Jānis Šmits Aug 17 '16 at 16:50
  • onIdle will only work good if you really can split your measurement into VERY small and fast steps. Generally threads are better - that's exactly what they were invented for, but you'll need to pass not a short and easy learning curve... – mvidelgauz Aug 17 '16 at 16:54
  • @JānisŠmits: I'd stay *away* from `onIdle` if at all possible. It was pretty much necessary on 16-bit Windows, and has been retained all these years primarily for the sake of backward compatibility. Your case fits much better with using a background thread. The docs get confusing because they cover lots of corner cases, but using them for a case like this is really quite simple. – Jerry Coffin Aug 17 '16 at 16:55
  • Ok, I will heed your advice and try to work through the docs/tutorials, thank you! I guess [this](https://msdn.microsoft.com/en-us/library/975t8ks0.aspx) is a good place to start? – Jānis Šmits Aug 17 '16 at 17:00
  • @JānisŠmits You are right but usually business interests cannot be just discarded (hard to admit it but I was beaten by my managers many times for doing _"just correct"_ things). If thread approach will take OP a week to implement and _bad_ onIdle will just work in 2 hours than this bad option has to be on the table for him to choose – mvidelgauz Aug 17 '16 at 17:05
  • @JerryCoffin my previous comment was for you actually, just typo... – mvidelgauz Aug 17 '16 at 17:30
  • @mvidelgauz: I would be rather surprised to see an OnIdle implementation done in 2 hours, but a thread-based implementation take a week. In fact, rather the opposite tends to be the case: using OnIdle requires that you split the task up into little pieces explicitly, where a thread-based version lets you just write your code normally, and then use a fairly simple bit of code to start it running in a separate thread. In this case, it looks like the result is being handled as Windows messages, in which case you need to use PostMessage instead SendMessage, but little else. – Jerry Coffin Aug 17 '16 at 18:36
  • @JerryCoffin Yes, I know what you are talking about, you are right. But it depends on that worker task. Sometimes it is naturaly split in small steps without inventing a special algorithm to achive it, while threads require syncing, at least to stop. Anyway, what I am standing with is that both options do exist and it is OP who should make a choice (probably by trial) taking business goal and schedule as priority – mvidelgauz Aug 17 '16 at 18:53
  • @JerryCoffin _"I would be rather surprised to see ... a thread-based implementation take a week"_ take into account that OP is not experienced programmer... His words: _" I had a hard time understanding the various tutorials on worker/UI threads"_ – mvidelgauz Aug 17 '16 at 19:31
  • @mvidelgauz: I did take that into account. The fact is, that `OnIdle` is a *pain* to use well. Using enough to use a thread reasonably well isn't nearly as much work. – Jerry Coffin Aug 17 '16 at 21:01
  • @JerryCoffin Ok, I think we gave OP enough info to start with. If he will have another questions we'll see them – mvidelgauz Aug 17 '16 at 21:40
  • You make it sound that you chose MFC because you have to use an ActiveX control. MFC is not required to use an ActiveX control. A plain Windows API (maybe with ATL to make COM easier and safer) would do just fine. Just mentioning this, since MFC has a steep learning curve attached as well. – IInspectable Aug 18 '16 at 03:24

0 Answers0