Application.DoE vents() and COM

[Ollie Riches]

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need to
call DoEvents when I am using a COM component that calls back to into the
..Net application? - If I don't call DoEvents after receiving a callback then
sometimes no more messages are pumped, it appears that the message pump is
suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that it
will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Willy Denoyette [MVP]]

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not clear
is where you call DoEvents() on a UI thread that is not pumping, so it looks
like your code blocks the message while running in a tight loop and you call
DoEvents in the loop.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Ollie Riches]

Thanks for the reply Willy,

If you should never call DoEvents() then I have to ask why was it included? I believe it is similar to including GC.Collect in that it is exposed to the public for use in extreme circumstances.

I can understand that while a message is being processed that no other message can be processed hence the name synchronous message processing.

I can give an example taken straight from the support site of the product I am using, you can probably guess the product involved in the code. I am well aware that any code published on any site is not always the correct way to solve a problem. The code in question uses the primary interop assembly that was generated by the vendor.

If you are using (primary) COM interop library are you required to initialise COM ? - as far as I am aware you do not have too.

Here is the complete winforms example, check out the method 'Display_Instru ment_Informatio n'
Cheers

Ollie Riches

using System;

using System.Drawing;

using System.Collecti ons;

using System.Componen tModel;

using System.Windows. Forms;

using System.Data;

namespace PriceUpdate

{

/// <summary>

/// Summary description for Form1.

/// </summary>

public class Form1 : System.Windows. Forms.Form

{

private System.Windows. Forms.Label label1;

private System.Windows. Forms.Label label2;

private System.Windows. Forms.Label label3;

private System.Windows. Forms.Label label4;

private System.Windows. Forms.Label label5;

private System.Windows. Forms.Label lblContract;

private System.Windows. Forms.Label lblProdTape;

private System.Windows. Forms.Label lblProduct;

private System.Windows. Forms.Label lblExchange;

private System.Windows. Forms.Label label6;

private System.Windows. Forms.Label label7;

private System.Windows. Forms.Label label8;

private System.Windows. Forms.Label label9;

private System.Windows. Forms.Label label14;

private System.Windows. Forms.Label label15;

private System.Windows. Forms.Label lblAskQty;

private System.Windows. Forms.Label lblAskPrice;

private System.Windows. Forms.Label lblBidQty;

private System.Windows. Forms.Label lblBidPrice;

private System.Windows. Forms.Label lblLastQty;

private System.Windows. Forms.Label lblLastPrice;

/// <summary>

/// Required designer variable.

/// </summary>

private System.Componen tModel.Containe r components = null;

// using XTAPI objects

// this sample will need the drag and drop handler class,

// the Instrument object to temporary hold the selected instrument,

// and the instrument notification class for price updates

private XTAPI.TTDropHan dlerClass m_DropHandler = null;

private XTAPI.TTInstrOb j m_LiveInstr = null;

private XTAPI.TTInstrNo tifyClass m_InstrNotify = null;

public Form1()

{

//

// Required for Windows Form Designer support

//

InitializeCompo nent();

}

/// <summary>

/// Clean up any resources being used.

/// </summary>

protected override void Dispose( bool disposing )

{

if( disposing )

{

if (components != null)

{

components.Disp ose();

}

}

base.Dispose( disposing );

}

#region Windows Form Designer generated code

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

private void InitializeCompo nent()

{

this.label1 = new System.Windows. Forms.Label();

this.label2 = new System.Windows. Forms.Label();

this.label3 = new System.Windows. Forms.Label();

this.label4 = new System.Windows. Forms.Label();

this.label5 = new System.Windows. Forms.Label();

this.lblContrac t = new System.Windows. Forms.Label();

this.lblProdTap e = new System.Windows. Forms.Label();

this.lblProduct = new System.Windows. Forms.Label();

this.lblExchang e = new System.Windows. Forms.Label();

this.label6 = new System.Windows. Forms.Label();

this.label7 = new System.Windows. Forms.Label();

this.label8 = new System.Windows. Forms.Label();

this.label9 = new System.Windows. Forms.Label();

this.lblAskQty = new System.Windows. Forms.Label();

this.lblAskPric e = new System.Windows. Forms.Label();

this.lblBidQty = new System.Windows. Forms.Label();

this.lblBidPric e = new System.Windows. Forms.Label();

this.label14 = new System.Windows. Forms.Label();

this.label15 = new System.Windows. Forms.Label();

this.lblLastQty = new System.Windows. Forms.Label();

this.lblLastPri ce = new System.Windows. Forms.Label();

this.SuspendLay out();

//

// label1

//

this.label1.Loc ation = new System.Drawing. Point(16, 123);

this.label1.Nam e = "label1";

this.label1.Siz e = new System.Drawing. Size(96, 16);

this.label1.Tab Index = 17;

this.label1.Tex t = "CONTRACT:" ;

//

// label2

//

this.label2.Loc ation = new System.Drawing. Point(16, 88);

this.label2.Nam e = "label2";

this.label2.Siz e = new System.Drawing. Size(96, 16);

this.label2.Tab Index = 16;

this.label2.Tex t = "PRODUCT TYPE:";

//

// label3

//

this.label3.Loc ation = new System.Drawing. Point(16, 56);

this.label3.Nam e = "label3";

this.label3.Siz e = new System.Drawing. Size(96, 16);

this.label3.Tab Index = 15;

this.label3.Tex t = "PRODUCT:";

//

// label4

//

this.label4.Loc ation = new System.Drawing. Point(16, 19);

this.label4.Nam e = "label4";

this.label4.Siz e = new System.Drawing. Size(96, 16);

this.label4.Tab Index = 14;

this.label4.Tex t = "EXCHANGE:" ;

//

// label5

//

this.label5.Loc ation = new System.Drawing. Point(144, 256);

this.label5.Nam e = "label5";

this.label5.Siz e = new System.Drawing. Size(232, 56);

this.label5.Tab Index = 13;

this.label5.Tex t = "Drag an instrument from X_Trader Market Grid and drop it anywhere on this form.";

//

// lblContract

//

this.lblContrac t.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblContrac t.Location = new System.Drawing. Point(128, 120);

this.lblContrac t.Name = "lblContrac t";

this.lblContrac t.TabIndex = 12;

//

// lblProdTape

//

this.lblProdTap e.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblProdTap e.Location = new System.Drawing. Point(128, 88);

this.lblProdTap e.Name = "lblProdTap e";

this.lblProdTap e.TabIndex = 18;

//

// lblProduct

//

this.lblProduct .BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblProduct .Location = new System.Drawing. Point(128, 56);

this.lblProduct .Name = "lblProduct ";

this.lblProduct .TabIndex = 19;

//

// lblExchange

//

this.lblExchang e.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblExchang e.Location = new System.Drawing. Point(128, 16);

this.lblExchang e.Name = "lblExchang e";

this.lblExchang e.TabIndex = 20;

//

// label6

//

this.label6.Loc ation = new System.Drawing. Point(264, 120);

this.label6.Nam e = "label6";

this.label6.Siz e = new System.Drawing. Size(96, 16);

this.label6.Tab Index = 25;

this.label6.Tex t = "ASK QTY:";

//

// label7

//

this.label7.Loc ation = new System.Drawing. Point(264, 88);

this.label7.Nam e = "label7";

this.label7.Siz e = new System.Drawing. Size(96, 16);

this.label7.Tab Index = 24;

this.label7.Tex t = "ASK PRICE:";

//

// label8

//

this.label8.Loc ation = new System.Drawing. Point(264, 56);

this.label8.Nam e = "label8";

this.label8.Siz e = new System.Drawing. Size(96, 16);

this.label8.Tab Index = 23;

this.label8.Tex t = "BID QTY:";

//

// label9

//

this.label9.Loc ation = new System.Drawing. Point(264, 19);

this.label9.Nam e = "label9";

this.label9.Siz e = new System.Drawing. Size(96, 16);

this.label9.Tab Index = 22;

this.label9.Tex t = "BID PRICE:";

//

// lblAskQty

//

this.lblAskQty. BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblAskQty. Location = new System.Drawing. Point(376, 120);

this.lblAskQty. Name = "lblAskQty" ;

this.lblAskQty. TabIndex = 21;

//

// lblAskPrice

//

this.lblAskPric e.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblAskPric e.Location = new System.Drawing. Point(376, 88);

this.lblAskPric e.Name = "lblAskPric e";

this.lblAskPric e.TabIndex = 26;

//

// lblBidQty

//

this.lblBidQty. BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblBidQty. Location = new System.Drawing. Point(376, 56);

this.lblBidQty. Name = "lblBidQty" ;

this.lblBidQty. TabIndex = 27;

//

// lblBidPrice

//

this.lblBidPric e.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblBidPric e.Location = new System.Drawing. Point(376, 16);

this.lblBidPric e.Name = "lblBidPric e";

this.lblBidPric e.TabIndex = 28;

//

// label14

//

this.label14.Lo cation = new System.Drawing. Point(264, 184);

this.label14.Na me = "label14";

this.label14.Si ze = new System.Drawing. Size(96, 16);

this.label14.Ta bIndex = 31;

this.label14.Te xt = "LAST QTY:";

//

// label15

//

this.label15.Lo cation = new System.Drawing. Point(264, 152);

this.label15.Na me = "label15";

this.label15.Si ze = new System.Drawing. Size(96, 16);

this.label15.Ta bIndex = 30;

this.label15.Te xt = "LAST PRICE:";

//

// lblLastQty

//

this.lblLastQty .BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblLastQty .Location = new System.Drawing. Point(376, 184);

this.lblLastQty .Name = "lblLastQty ";

this.lblLastQty .TabIndex = 29;

//

// lblLastPrice

//

this.lblLastPri ce.BorderStyle = System.Windows. Forms.BorderSty le.Fixed3D;

this.lblLastPri ce.Location = new System.Drawing. Point(376, 152);

this.lblLastPri ce.Name = "lblLastPri ce";

this.lblLastPri ce.TabIndex = 32;

//

// Form1

//

this.AutoScaleB aseSize = new System.Drawing. Size(5, 13);

this.ClientSize = new System.Drawing. Size(496, 341);

this.Controls.A dd(this.label14 );

this.Controls.A dd(this.label15 );

this.Controls.A dd(this.lblLast Qty);

this.Controls.A dd(this.lblLast Price);

this.Controls.A dd(this.label6) ;

this.Controls.A dd(this.label7) ;

this.Controls.A dd(this.label8) ;

this.Controls.A dd(this.label9) ;

this.Controls.A dd(this.lblAskQ ty);

this.Controls.A dd(this.lblAskP rice);

this.Controls.A dd(this.lblBidQ ty);

this.Controls.A dd(this.lblBidP rice);

this.Controls.A dd(this.label1) ;

this.Controls.A dd(this.label2) ;

this.Controls.A dd(this.label3) ;

this.Controls.A dd(this.label4) ;

this.Controls.A dd(this.label5) ;

this.Controls.A dd(this.lblCont ract);

this.Controls.A dd(this.lblProd Tape);

this.Controls.A dd(this.lblProd uct);

this.Controls.A dd(this.lblExch ange);

this.Name = "Form1";

this.Text = " Price Update From";

this.Load += new System.EventHan dler(this.Form1 _Load);

this.ResumeLayo ut(false);

}

#endregion

/// <summary>

/// The main entry point for the application.

/// </summary>

///

[STAThread]

static void Main()

{

Application.Run (new Form1());

}

private void Form1_Load(obje ct sender, System.EventArg s e)

{

// initilize XTAPI needed classes and/or objects

// Instantiate the drag and drop handler class

m_DropHandler = new XTAPI.TTDropHan dlerClass();

// register the active window to enable drag and drop

m_DropHandler.R egisterDropWind ow((int) this.Handle);

// associate drop and drag events with the handler

m_DropHandler.O nNotifyDrop += new XTAPI._ITTDropH andlerEvents_On NotifyDropEvent Handler(this.m_ DropHandler_OnN otifyDrop);
// instantiate the instrument notification class

m_InstrNotify = new XTAPI.TTInstrNo tifyClass();

// associate instrument notification events with the instrument notification class

// setup the instrument notification call back function

m_InstrNotify.O nNotifyFound += new XTAPI._ITTInstr NotifyEvents_On NotifyFoundEven tHandler(this.m _InstrNotify_On NotifyFound);

// setup the instrument update call back function

m_InstrNotify.O nNotifyUpdate += new XTAPI._ITTInstr NotifyEvents_On NotifyUpdateEve ntHandler(this. m_InstrNotify_O nNotifyUpdate);

}

// XTAPI specific used functions

private void m_DropHandler_O nNotifyDrop()

{ // drag and drop call back function

try

{

// get live instrument from the call back - Index starts at 1

// cast the call back instrument as an instrument object

m_LiveInstr = (XTAPI.TTInstrO bj) m_DropHandler[1]; // 1 for a single instrument

// **** 88888888888888 *************

// must attach instrument to the notification object

m_InstrNotify.A ttachInstrument (m_LiveInstr);

// **** 88888888888888 *************
// open / access selected instrument

m_LiveInstr.Ope n(0); // turn off depth
// clear drop handler list

m_DropHandler.R eset();

}

catch (Exception e)

{

MessageBox.Show (e.Message,"Exc eption");

}

}

private void m_InstrNotify_O nNotifyFound(XT API.TTInstrNoti fy pNotify, XTAPI.TTInstrOb j pInstr)

{

// retrieve and display instrument information

Display_Instrum ent_Information (pInstr);

// retrieve and display pricing information

Get_Live_Data(p Instr);

// turn on price updates

m_InstrNotify.E nablePriceUpdat es = 1; // 1 for true

}

private void m_InstrNotify_O nNotifyUpdate(X TAPI.TTInstrNot ify pNotify, XTAPI.TTInstrOb j pInstr)

{

// retrieve live instrument prices

Get_Live_Data(p Instr);

}

private void Display_Instrum ent_Information (XTAPI.TTInstrO bj pInstr)

{

// display instrument fields onto labels

this.lblExchang e.Text = pInstr.Exchange ;

this.lblProduct .Text = pInstr.Product;

this.lblProdTap e.Text = pInstr.ProdType ;

this.lblContrac t.Text = pInstr.Contract ;

Application.DoE vents(); // force update in case it does not

}

private void Get_Live_Data(X TAPI.TTInstrObj pInstr)

{

// display instrument pricing information onto labels

this.lblBidQty. Text = (string) pInstr.get_Get( "BidQty$");

this.lblBidPric e.Text = (string) pInstr.get_Get( "Bid$");

this.lblAskPric e.Text = (string) pInstr.get_Get( "Ask$");

this.lblAskQty. Text= (string) pInstr.get_Get( "AskQty$");

this.lblLastPri ce.Text = (string) pInstr.get_Get( "Last$");

this.lblLastQty .Text = (string) pInstr.get_Get( "LastQty$") ;

Application.DoE vents(); // force update in case it does not

}

}

}
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:eg******** ******@TK2MSFTN GP10.phx.gbl...

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not clear
is where you call DoEvents() on a UI thread that is not pumping, so it looks
like your code blocks the message while running in a tight loop and you call
DoEvents in the loop.

Willy.




"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Willy Denoyette [MVP]]

Well I really don't know why DoEvents included, but it's heritage is VB so I guess we have to look that way. Anyway there is no need ever to call DoEvents because there is a better solution and because it's not re-entrant safe.
Now as for this code, I can hardly be sure for 100% what's going on without any more info on the COM library itself (would like to know it's threadingmodel) .
What I see is that the UI is only meant to display data, there are no input controls (buttons etc...) only output controls (labels), and the callbacks are only used to update the labels at regular intervals. There are no calls made to the COM object from the UI, that means if the COM object doesn't return after the callback, that is when it blocks (in a sleep call fi) without pumping the message queue, you are screwed, and you have to resort to hacks like DoEvents() to update the UI (redraw) before you return from the eventhandler. Again without seeing the source code of the COM objects it's hard to be sure for 100% , but I wouldn't be surprised it's like that.
All you have to do to get rid of the DoEvents hack, is create a separate thread initialized for STA, create an instance of the COM object and update the UI using Control.BeginIn voke.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message news:us******** ******@tk2msftn gp13.phx.gbl...
Thanks for the reply Willy,

If you should never call DoEvents() then I have to ask why was it included? I believe it is similar to including GC.Collect in that it is exposed to the public for use in extreme circumstances.

I can understand that while a message is being processed that no other message can be processed hence the name synchronous message processing.

I can give an example taken straight from the support site of the product I am using, you can probably guess the product involved in the code. I am well aware that any code published on any site is not always the correct way to solve a problem. The code in question uses the primary interop assembly that was generated by the vendor.

If you are using (primary) COM interop library are you required to initialise COM ? - as far as I am aware you do not have too.

Here is the complete winforms example, check out the method 'Display_Instru ment_Informatio n'
Cheers

Ollie Riches

"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:eg******** ******@TK2MSFTN GP10.phx.gbl...

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not clear
is where you call DoEvents() on a UI thread that is not pumping, so it looks
like your code blocks the message while running in a tight loop and you call
DoEvents in the loop.

Willy.




"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Ollie Riches]

Thanks for the info Willy, I realised the solution after posting the reply - its always good to talk out a problem...

Cheers

Ollie Riches
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:O9******** ******@TK2MSFTN GP12.phx.gbl...
Well I really don't know why DoEvents included, but it's heritage is VB so I guess we have to look that way. Anyway there is no need ever to call DoEvents because there is a better solution and because it's not re-entrant safe.
Now as for this code, I can hardly be sure for 100% what's going on without any more info on the COM library itself (would like to know it's threadingmodel) .
What I see is that the UI is only meant to display data, there are no input controls (buttons etc...) only output controls (labels), and the callbacks are only used to update the labels at regular intervals. There are no calls made to the COM object from the UI, that means if the COM object doesn't return after the callback, that is when it blocks (in a sleep call fi) without pumping the message queue, you are screwed, and you have to resort to hacks like DoEvents() to update the UI (redraw) before you return from the eventhandler. Again without seeing the source code of the COM objects it's hard to be sure for 100% , but I wouldn't be surprised it's like that.
All you have to do to get rid of the DoEvents hack, is create a separate thread initialized for STA, create an instance of the COM object and update the UI using Control.BeginIn voke.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message news:us******** ******@tk2msftn gp13.phx.gbl...
Thanks for the reply Willy,

If you should never call DoEvents() then I have to ask why was it included? I believe it is similar to including GC.Collect in that it is exposed to the public for use in extreme circumstances.

I can understand that while a message is being processed that no other message can be processed hence the name synchronous message processing.

I can give an example taken straight from the support site of the product I am using, you can probably guess the product involved in the code. I am well aware that any code published on any site is not always the correct way to solve a problem. The code in question uses the primary interop assembly that was generated by the vendor.

If you are using (primary) COM interop library are you required to initialise COM ? - as far as I am aware you do not have too.

Here is the complete winforms example, check out the method 'Display_Instru ment_Informatio n'
Cheers

Ollie Riches

"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:eg******** ******@TK2MSFTN GP10.phx.gbl...

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not clear
is where you call DoEvents() on a UI thread that is not pumping, so it looks
like your code blocks the message while running in a tight loop and you call
DoEvents in the loop.

Willy.




"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Ollie Riches]

Turns out the problem was related to the threading model, it should have been MTA not STA, with the wrong threading apartment the code required the use of Application.DoE vents().

So the next question is - why would having the wrong thread apartment for an unmanaged COM component cause the message pump to not work correctly and require the use of Application.DoE vents()?
Cheers

Ollie Riches

"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message news:un******** ******@TK2MSFTN GP10.phx.gbl...
Thanks for the info Willy, I realised the solution after posting the reply - its always good to talk out a problem...

Cheers

Ollie Riches
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:O9******** ******@TK2MSFTN GP12.phx.gbl...
Well I really don't know why DoEvents included, but it's heritage is VB so I guess we have to look that way. Anyway there is no need ever to call DoEvents because there is a better solution and because it's not re-entrant safe.
Now as for this code, I can hardly be sure for 100% what's going on without any more info on the COM library itself (would like to know it's threadingmodel) .
What I see is that the UI is only meant to display data, there are no input controls (buttons etc...) only output controls (labels), and the callbacks are only used to update the labels at regular intervals. There are no calls made to the COM object from the UI, that means if the COM object doesn't return after the callback, that is when it blocks (in a sleep call fi) without pumping the message queue, you are screwed, and you have to resort to hacks like DoEvents() to update the UI (redraw) before you return from the eventhandler. Again without seeing the source code of the COM objects it's hard to be sure for 100% , but I wouldn't be surprised it's like that.
All you have to do to get rid of the DoEvents hack, is create a separate thread initialized for STA, create an instance of the COM object and update the UI using Control.BeginIn voke.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message news:us******** ******@tk2msftn gp13.phx.gbl...
Thanks for the reply Willy,

If you should never call DoEvents() then I have to ask why was it included? I believe it is similar to including GC.Collect in that it is exposed to the public for use in extreme circumstances.

I can understand that while a message is being processed that no other message can be processed hence the name synchronous message processing.

I can give an example taken straight from the support site of the product I am using, you can probably guess the product involved in the code. I am well aware that any code published on any site is not always the correct way to solve a problem. The code in question uses the primary interop assembly that was generated by the vendor.

If you are using (primary) COM interop library are you required to initialise COM ? - as far as I am aware you do not have too.

Here is the complete winforms example, check out the method 'Display_Instru ment_Informatio n'
Cheers

Ollie Riches

"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message news:eg******** ******@TK2MSFTN GP10.phx.gbl...

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not clear
is where you call DoEvents() on a UI thread that is not pumping, so it looks
like your code blocks the message while running in a tight loop and you call
DoEvents in the loop.

Willy.




"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches

[Dmytro Lapshyn [MVP]]

Ollie,

Any STA COM object requires the thread on which it is created to run the
message pump. It is due to the way the system serializes calls to STA COM
objects - the calls are marshalled as private Windows messages to a
dedicated hidden window, "OleMainThreadW nd" (not sure about exact spelling).
If an STA thread makes a blocking call and stops processing Windows
messages, no calls can be forwarded to any COM component in the STA
apartment the thread belongs to. Application.DoE vents forces the Framework
to process accumulated messages, thus allowing any serialized calls to
complete. Does this answer your question?

--
Sincerely,
Dmytro Lapshyn [Visual Developer - Visual C# MVP]

"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:ua******** ******@TK2MSFTN GP14.phx.gbl...
Turns out the problem was related to the threading model, it should have
been MTA not STA, with the wrong threading apartment the code required the
use of Application.DoE vents().

So the next question is - why would having the wrong thread apartment for an
unmanaged COM component cause the message pump to not work correctly and
require the use of Application.DoE vents()?
Cheers

Ollie Riches

"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:un******** ******@TK2MSFTN GP10.phx.gbl...
Thanks for the info Willy, I realised the solution after posting the reply -
its always good to talk out a problem...

Cheers

Ollie Riches
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:O9******** ******@TK2MSFTN GP12.phx.gbl...
Well I really don't know why DoEvents included, but it's heritage is VB so I
guess we have to look that way. Anyway there is no need ever to call
DoEvents because there is a better solution and because it's not re-entrant
safe.
Now as for this code, I can hardly be sure for 100% what's going on without
any more info on the COM library itself (would like to know it's
threadingmodel) .
What I see is that the UI is only meant to display data, there are no input
controls (buttons etc...) only output controls (labels), and the callbacks
are only used to update the labels at regular intervals. There are no calls
made to the COM object from the UI, that means if the COM object doesn't
return after the callback, that is when it blocks (in a sleep call fi)
without pumping the message queue, you are screwed, and you have to resort
to hacks like DoEvents() to update the UI (redraw) before you return from
the eventhandler. Again without seeing the source code of the COM objects
it's hard to be sure for 100% , but I wouldn't be surprised it's like that.
All you have to do to get rid of the DoEvents hack, is create a separate
thread initialized for STA, create an instance of the COM object and update
the UI using Control.BeginIn voke.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:us******** ******@tk2msftn gp13.phx.gbl...
Thanks for the reply Willy,

If you should never call DoEvents() then I have to ask why was it included?
I believe it is similar to including GC.Collect in that it is exposed to the
public for use in extreme circumstances.

I can understand that while a message is being processed that no other
message can be processed hence the name synchronous message processing.

I can give an example taken straight from the support site of the product I
am using, you can probably guess the product involved in the code. I am well
aware that any code published on any site is not always the correct way to
solve a problem. The code in question uses the primary interop assembly that
was generated by the vendor.

If you are using (primary) COM interop library are you required to
initialise COM ? - as far as I am aware you do not have too.

Here is the complete winforms example, check out the method
'Display_Instru ment_Informatio n'
Cheers

Ollie Riches

"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:eg******** ******@TK2MSFTN GP10.phx.gbl...

DoEvents() should never be called nor in a COM interop scenario and not on
the UI thread. All you have to do is make sure you don't block the message
pumping/dispatching by calling functions or running code that take a long
time before yielding (~300msec. might be too long for a decent user
experience). The same thing goes for a COM callback that runs on the UI
thread, messages aren't dispatched as long as the callback code runs.
Now it's hard to tell what happens in your code without some more context
(apartment requirements of COM object) and seeing any code; What's not
clear
is where you call DoEvents() on a UI thread that is not pumping, so it
looks
like your code blocks the message while running in a tight loop and you
call
DoEvents in the loop.

Willy.


"Ollie Riches" <ol**********@p honeanalyser.ne t> wrote in message
news:en******** ******@tk2msftn gp13.phx.gbl...

I understand the use of Application.DoE vents() to process all outstanding
messages on the message queue in a winforms application if you have long
running process on the UI thread. But can anyone explain to me why I need
to call DoEvents when I am using a COM component that calls back to into
the .Net application? - If I don't call DoEvents after receiving a
callback
then sometimes no more messages are pumped, it appears that the message
pump is suspended until the call is made.

I suspect that when a callback occurs from COM into the .Net process that
it will not be guaranteed to be executed on the UI thread is this true?
( Note: I do know about updating the UI thread from a worker thread so
people pleased don't try and tell me about the 'Invoke' method on the
Control class)

Cheers

Ollie Riches