C# validating event problem for a super genius

[Peted]

I have an amazing problem which i think i have no hope of solving

Im working with a c# dot net module that is hosted by and runs under a
delphi form envrioment. Dont ask me how this insanity has prevailed
it just is :)

My problem is this

im trying to validate the contents of a textbox (it has to be a normal
textbox) and on a c# winforms and i am calling the textbox validating
event to check for bad data entry and in doing so causing the

eg test example
e.Cancel = nameTextBox.Tex t.Contains("!") ;

to be set to true, to halt focus at the textbox when bad data is
entered. On its own it works fine, but when hosted under the delphi
form application once the validating event has fired it will not
release focus away from the textbox at all

I desperatly need a way to be able to cancel the validating event so
that i can use other buttons that have become not clickable on other
parts of the winforms.

As i said it all works perfectly when run in the studio dev
enviroment, but when run as it needs to hosted by a delphi forms app
we have verified the validating events just wont seem to release focus

if anyone has any ideas or thoughts it would be appreciated

thanks

Peted

[Ben Voigt [C++ MVP]]

Peted wrote:

I have an amazing problem which i think i have no hope of solving

Im working with a c# dot net module that is hosted by and runs under a
delphi form envrioment. Dont ask me how this insanity has prevailed
it just is :)

My problem is this

im trying to validate the contents of a textbox (it has to be a normal
textbox) and on a c# winforms and i am calling the textbox validating
event to check for bad data entry and in doing so causing the

eg test example
e.Cancel = nameTextBox.Tex t.Contains("!") ;

to be set to true, to halt focus at the textbox when bad data is
entered. On its own it works fine, but when hosted under the delphi
form application once the validating event has fired it will not
release focus away from the textbox at all

I desperatly need a way to be able to cancel the validating event so
that i can use other buttons that have become not clickable on other
parts of the winforms.

As i said it all works perfectly when run in the studio dev
enviroment, but when run as it needs to hosted by a delphi forms app
we have verified the validating events just wont seem to release focus

if anyone has any ideas or thoughts it would be appreciated

I would try creating the .NET controls from a separate thread which calls
Application.Run ... that way you have an event loop independent of the Delphi
one and any non-standard behavior it implements.

>
thanks

Peted

[Brian Gideon]

On Apr 29, 4:51*am, Peted wrote:

I have an amazing problem which i think i have no hope of solving

Im working with a c# dot net module that is hosted by and runs under a
delphi form envrioment. Dont ask me how this insanity has prevailed
it just is :)

My problem is this

im trying to validate the contents of a textbox (it has to be a normal
textbox) and on a c# winforms and i am calling the textbox validating
event to check for bad data entry and in doing so causing the

eg test example
*e.Cancel = nameTextBox.Tex t.Contains("!") ;

to be set to true, to halt focus at the textbox when bad data is
entered. On its own it works fine, but when hosted under the delphi
form application once the validating event has fired it will not
release focus away from the textbox at all

I desperatly need a way to be able to cancel the validating event so
that i can use other buttons that have become not clickable on other
parts of the winforms.

As i said it all works perfectly when run in the studio dev
enviroment, but when run as it needs to hosted by a delphi forms app
we have verified the validating events just wont seem to release focus

if anyone has any ideas or thoughts it would be appreciated

thanks

Peted

I second Ben suggestion. It's possible that the Delphi form
environment is filtering or dispatching messages differently which is
what is actually causing the problem. This is one of those rare
situations where I think having multiple message loops running is
okay. If that doesn't fix your problem then you have something deeper
than the application message pump to contend with, which seems
unlikely to me.

[Peted]

thanks for the advice

any chance you could point me to an example of creating .net controls
from seperate threads as you have described ?

thanks

Peted

>
I would try creating the .NET controls from a separate thread which calls
Application.Ru n... that way you have an event loop independent of the Delphi
one and any non-standard behavior it implements.

[Brian Gideon]

On Apr 29, 7:47*pm, Peted wrote:

thanks for the advice

any chance you could point me to an example of creating .net controls
from seperate threads as you have described ?

Start a thread like you would any other thread and then immediately
call Application.Run . It accepts a Form parameter which will
automatically be shown up execution of the method. It's no different
than code Visual Studio generates for you when you Windows Forms
application except that another thread is involved.

[Ben Voigt [C++ MVP]]

Brian Gideon wrote:

On Apr 29, 7:47 pm, Peted wrote:

>thanks for the advice

any chance you could point me to an example of creating .net controls
from seperate threads as you have described ?

Start a thread like you would any other thread and then immediately
call Application.Run . It accepts a Form parameter which will
automatically be shown up execution of the method. It's no different
than code Visual Studio generates for you when you Windows Forms
application except that another thread is involved.

Or if you want just a few controls, not the whole Form shown from the other
thread, you can call
new TextBox() or whatever control type
and read the Handle property to make sure it is created from the new thread,
then call the parent form's Controls.Add method, passing in the newly
created control.

[Brian Gideon]

On Apr 30, 1:14*pm, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

Or if you want just a few controls, not the whole Form shown from the other
thread, you can call
new TextBox() or whatever control type
and read the Handle property to make sure it is created from the new thread,
then call the parent form's Controls.Add method, passing in the newly
created control.

I hadn't thought about that before. I guess I've always been using
the assumption that this would cause chaos. How would the parent form
and the child control interact seeing as they are running on separate
threads? And from a developers perspective, writing code that
accesses the child control from the parent form would be cumbersome
and slow since everything would have to be marshaled between the
threads to maintain the thread affinity requirements right?

[Ben Voigt [C++ MVP]]

Brian Gideon wrote:

On Apr 30, 1:14 pm, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

>Or if you want just a few controls, not the whole Form shown from
the other thread, you can call
new TextBox() or whatever control type
and read the Handle property to make sure it is created from the new
thread, then call the parent form's Controls.Add method, passing in
the newly created control.

I hadn't thought about that before. I guess I've always been using
the assumption that this would cause chaos. How would the parent form

Plugins are often hosted on another thread (embedded video player, acrobat
reader, that sort of thing).

and the child control interact seeing as they are running on separate
threads? And from a developers perspective, writing code that

Using windows messages SendMessage(WM_ *, ...), often via a helper such as
GetWindowText or GetDlgItemText, same as they do from the same thread.

accesses the child control from the parent form would be cumbersome
and slow since everything would have to be marshaled between the
threads to maintain the thread affinity requirements right?

This "thread affinity" thing is an artificial creation of .NET.

The underlying windows calls work just fine across threads. And if your
control is hosted in a non-.NET form, then all the extra .NET baggage that
makes threading assumptions isn't present anyway.

[Brian Gideon]

On May 1, 8:45*am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

Brian Gideon wrote:

On Apr 30, 1:14 pm, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

Or if you want just a few controls, not the whole Form shown from
the other thread, you can call
new TextBox() or whatever control type
and read the Handle property to make sure it is created from the new
thread, then call the parent form's Controls.Add method, passing in
the newly created control.

I hadn't thought about that before. *I guess I've always been using
the assumption that this would cause chaos. *How would the parent form

Plugins are often hosted on another thread (embedded video player, acrobat
reader, that sort of thing).

and the child control interact seeing as they are running on separate
threads? *And from a developers perspective, writing code that

Using windows messages SendMessage(WM_ *, ...), often via a helper such as
GetWindowText or GetDlgItemText, same as they do from the same thread.

accesses the child control from the parent form would be cumbersome
and slow since everything would have to be marshaled between the
threads to maintain the thread affinity requirements right?

This "thread affinity" thing is an artificial creation of .NET.

The underlying windows calls work just fine across threads. *And if your
control is hosted in a non-.NET form, then all the extra .NET baggage that
makes threading assumptions isn't present anyway.

Excellent. Ya know...I've doing this for a long time so it just goes
to show that there will always be something to learn!