The same symptoms showed on computers running XP so it wasn't a Windows 7
change - would multithreading events be there too?
John
Hi John,
This is pure speculation:
I suspect that the events are somehow multi-threaded or not as dependent on
each other as they used to be. This could have something to do with the fact
that you now on Win7 and 2007. The thing pointing me in that direction is the
XP Manifest stuff. I think it alters a lot more under Win7. Oh, and then there
is the fact that you say it works sometimes, and others not...sounds like two
threads running and you want thread 2 to finish before thread 1...99% of the
time they do, then the time slicing kicks in and the code "breaks"
Anyways - well spotted and I like your saying !
Cheers,
Pieter
On 11/06/2010 03:13, John Bird wrote:
I have solved it.
Had to do bit by bit testing and deductive reasoning to find the cause: The
bit by bit found nothing but took lots of nice time trying useless things.
The deductive reasoning - this is my oldest program, and was written before I
understood clearly the difference between the form onActivate and onShow
events. I had some code in the main form onActivate event that did quite a
lot of setups - including showing the second form which in its onActivate event
did some further processing. I am guessing this is to use a technical term
"asking for weird stuff" . Moving all the code to the onShow event in both
forms fixed the problem. Well I think that's what fixed it.
Why did I do it this way with the onActivate event, which fires every time
the main form is returned to? Well no-one ever told me otherwise, so I had
already put in code that made it only fire most of the code once ever,
effectively it was an onShow event. And also on the list of events Activate is
right at the top and Show is right at the bottom, and I was teaching myself
this stuff.
The other mystery which I am not going to try to figure is that for over 6
years it has worked fine, and something minor altered recently has thrown it.
I think it was when I added a combo box to the main form. Even then most of
the time it worked fine, but often would not. The main symptom was the edit
not getting proper focus - go figure!
I remember a saying on the door of one of my Physics lecturers - "This
problem - once solved - will be simple"
John
Yes I have tried all sorts of things like setting TabStop to false, and most
hopefully setting the control second in the Tab Order list with focus going to
another control and then doing a Setfocus to the one I want. It still does
not fix it. Also been playing with Autoselect and ShowSelect, and IMEMode.
Nothing makes any difference - I am convinced its something in the way the
program is built
Is there a way to programatically set the focus more than what Setfocus does?
John
Hi John,
Have you tried to set the tab order to 1 (or 0 - can't remember which is the
"accepted" first) for this control ?
Cheers,
Pieter
On 10/06/2010 21:20, John Bird wrote:
This one has me foxed. I have a standard unit which is a form dialog at
the start of many programs - which gets an access code and a password.
In one program only it misbehaves - the Tedit fields never seem to get
focus properly, so although the users can type text, there is no cursor and the
onexit event of the TEdit does not fire. Also default text in the Tedit does
not show as selected. Subsequent returns to this and other edit boxes do
behave properly.
This is Delphi 2007 - problem shows for this program on Windows 7 and XP.
XP Manifest is in use. Very little processing before this dialog form is
shown...
Note I have already done code like Edit1.Setfocus -- it does not fix the
problem.
Anyone have any ideas??? Normal build and compile all and deleting all
dcus has not fixed it.
Also is there any way to force a Tedit to have its text selected.
John
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
--------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe