This one is probably correct by nature, but it sounds like it worked for you from your description. I launch a modal form which then launches a fsStayOnTop form above it. The fsStayOnTop form is unable to get input
- the modal form under it prevents that apparently. If I was running windows I guess I'd probably hear the familiar "DING" when clicking the calendar. That's probably correct behavior and more a flaw in my thought process of what I _expected_ to happen.

Okay... I've tried so many things I've probably confused myself by now. I'll set it back that way and verify that it won't take input when used from a Modal form. If it works for you maybe I need to revert to an older version of the calendar code and try that.

Thanks,

-Tony

Yes. But it's meant to be a workaround on modal forms where certain things just weren't working right. A modal form doesn't like when it launches another form on top of the modal one apparently ;-D

can you elaborate on this.. I tried basic modal on top of modal when I was testing out the close/hide fix, and things seemed to work okay, but so far you and I see seem to be on different worlds when it comes to these problems. ;-)

nice imagery... I like.. :)

hmmm. I would suggest first going back to the way it was, because I am having absolutly no issues with your control, on modal forms, on modal on top of modal et-al, so long as it uses show, not showmodal on the popup form. If you continue to have issues.. post them. better to try and do things the proper way, and fix any issues resulting, then create a hack and still have to go back and fix things later, after all these things are problems in the LCL, which should be fixed anyway, and if I or anyone else can fix them all the better for everybody, not just you.

Do you think it's possible for me to hook a message that would allow my control to spy on the onenter event application wide, and hide itself when any form other than itself gets an onenter event?

It is possible on a purely GTK level. but there is that again.

I think it would be a good idea to be able to intercept these sorts of things on a LCL level, so that any control can create its own interceptions for special purpose controls etc. however this is rather complex and while I understand the basics, because I do not have the experiance it would take me days perhaps weeks to figure out this by myself, so ... perhaps later.

Andrew

_________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com

----Original Message Follows----
From: Tony Maro
Reply-To:
To:
Subject: Re: [lazarus] OnExit event...
Date: 29 Sep 2002 21:39:22 -0500

was

testing out the close/hide fix, and things seemed to work okay, but so

far

oh.. oh.oh.oh!!! this is not a flaw in your thought process. this is what I was talking about the other day, fsStayOnTop doesn't do squat.. I was basing my tests on a system with my code for using popup, which caused problems in your code, so I switched back in the patch last night. Arrgh one fix causes another issue.. I have got to figure out why popup forms don't recive onleave code, or how to make a dialog form..stay on top!!!!

Andrew

_________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

In my attempts to work around some of the modal issues

Which modal issues? The Close one? or are there other problems you didn't post? If so..well, do so.. they can't be fixed if they aren't known about.

hrmm.. hope you realize the problems this can introduce with auto Size/scroll'ing, on smaller screen resolutions, edge of screen , beyond screen etc..

the event on the panel, or on the Calendar?

If I create and show the panel and calendar, and DONT call setfocus, it never fires the onexit event. I have no way of tracking when a user clicks out of the TCalendar component.

Well.. not to beat this issue to the ground, but AFAIK none the focus/non-focus events, tabbing or losefocus/gain focus work quite right, because focusing is handled in a method very different in GTK then in Win32, so until focusing/tabbing events and functions are handled mostly by the LCL or interface, things will work inccorectly. To this end I have gotten the GTK+/Gnome App. Dev. Book to try and learn about Signal vs Callbacks, focusing tabbing et all, along with of course having a more comprehensive source than simply reading GTK source code, or incomplete API's(the tutorial is mostly useless in the areas I know nothing about..)

Any ideas? If you guys need deeper info I can post the app, but it's getting pretty big...

No not really.. except for the above. I don't really need to see the app. I think I know what you mean, and I can look into, but.... well anyway I don't want to rehash all the problems inherent in doing things the Win32 way in a GTK evironment, but suffice it to say while on enter/exit events do exist in GTK, they do not work exactly the same way as you would expect from a Win32, or even a QT design.. aka Delphi/Kylix. I will see what I can dredge up but this is not an area I am all that well informed on in GTK or Win32, as it is not something I have ever really used on an API level.. only Delphi, which is the problem with relying to much on platform specific RAD'S..

Andrew

_________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

In my attempts to work around some of the modal issues and such here's what I've tried and run into:

I've added a property to the TMCalEdit control called "ShowAsPanel" that instead of popping up a window will actually create a panel on the form that houses the edit box, just under the edit box.

I've tried handling the OnExit event for the calendar control, but one of two things happens.

If I create and show the panel and calender, then call setfocus on the calendar, it instantly fires the onexit event.

If I create and show the panel and calendar, and DONT call setfocus, it never fires the onexit event. I have no way of tracking when a user clicks out of the TCalendar component.

Any ideas? If you guys need deeper info I can post the app, but it's getting pretty big...

-Tony

Andrew Johnson wrote

hrmm.. hope you realize the problems this can introduce with auto Size/scroll'ing, on smaller screen resolutions, edge of screen , beyond screen etc..

Yes. But it's meant to be a workaround on modal forms where certain things just weren't working right. A modal form doesn't like when it launches another form on top of the modal one apparently ;-D

>If I create and show the panel and calender, then call setfocus on the >calendar, it instantly fires the onexit event. the event on the panel, or on the Calendar?

Well, the calendar will fire off as soon as you setfocus on it (or maybe it's before setfocus, I'll have to check that... the Panel just never gets the event at all, either way.

I just tested and learned that the doubleclick event that I'm using to launch the calendar pop-up is triggering a setfocus on the text box AFTER the double-click code is run. I'm assuming that it's firing a onclick event after the ondblclick event and then setting the focus back to the control. This immediately makes the pop-up disappear, of course, because the calendar looses focus. Launching the calendar from a TButton using the activate method works just fine... This is probably by design and would probably function the same way in Delphi but I haven't tested it.

Well.. not to beat this issue to the ground, but AFAIK none the focus/non-focus events, tabbing or losefocus/gain focus work quite right,

Well, there you have it then! I'm beating a dead horse with a wet noodle expecting to accomplish something! Sorry to bother all... lol

want to rehash all the problems inherent in doing things the Win32 way in a GTK evironment, but suffice it to say while on enter/exit events do exist in GTK, they do not work exactly the same way as you would expect from a Win32, or even a QT design.. aka Delphi/Kylix. I will see what I can dredge up but

Mmm... I can understand that. So the next question becomes - and I think you know what I'm trying to accomplish with this control - do you have a better suggestion for detecting lost focus when someone clicks out of the pop-up? I can always go back to the close button approach... but was trying to keep from doing that. I know absolutely nothing about GTK programming, so hooking in at GTK level is out of the question for me (at least for another 6 months.)

Do you think it's possible for me to hook a message that would allow my control to spy on the onenter event application wide, and hide itself when any form other than itself gets an onenter event?

-Tony