Calendar causes app to stay resident
Calendar causes app to stay resident
I have been trying to help Gerrit Ferwerda isolate a problem with the CodeJock Calendar system in his app.
He has the CJCALENDAR on a tabpage and has it hooked to the date picker.
Everything is functioning perfectly (BTW - the app looks great!!) except that the app remains in the task manager even after quitting.
Obviously, a CodeJock ActiveX control is not being properly destroyed but we cannot figure out why.
Has anyone experienced this problem?
He has the CJCALENDAR on a tabpage and has it hooked to the date picker.
Everything is functioning perfectly (BTW - the app looks great!!) except that the app remains in the task manager even after quitting.
Obviously, a CodeJock ActiveX control is not being properly destroyed but we cannot figure out why.
Has anyone experienced this problem?
The eXpress train is coming - and it has more cars.
Re: Calendar causes app to stay resident
what Dataprovider does he use ? if MAPI most Outlook Calender does not close connection.rdonnay wrote:Obviously, a CodeJock ActiveX control is not being properly destroyed but we cannot figure out why.
p.s. can he use multiresources in Codejock Calendar ?
greetings by OHR
Jimmy
Jimmy
Re: Calendar causes app to stay resident
Hi Roger,
I have the Codejock calendar in use at a lot of customers sites without any problem.
Only problem I found is that with too many appointments in the database an error sometimes arise. If the calendar is still loading data and you want to add another appointment, an error occured.
I have the Codejock calendar in use at a lot of customers sites without any problem.
Only problem I found is that with too many appointments in the database an error sometimes arise. If the calendar is still loading data and you want to add another appointment, an error occured.
-
- Posts: 8
- Joined: Wed Aug 18, 2010 11:07 am
Re: Calendar causes app to stay resident
Hi, I am another developer at Ferrus who is working with this problem. Mostly through trial and error, I have isolated the problem to a select set of circumstances:
1) A CJDatePicker or CJCalendarCaptionBar is created, and the method oCaptionbar:attachToCalendar(oCalendar) or oDatePicker:attachToCalendar(oCalendar) is called. Note that it is the attachToCalendar part that is the problem. We can make the controls fine, it is only if they are attached that they cause the program to not close.
2) Closing the program with the QUIT command, instead of returning from the Main() function. Our program needs to close with QUIT because we need to be able to break out of the program from anywhere in it, even if we are nested several function calls deep.
Note that we are correctly calling oCaptionBar:detachFromCalendar() and oDatePicker:detachFromCalendar(), but that seems to have no affect. Also, disabling the data provider entirely seemed to have no affect.
I have modified Roger's codejock calendar demo to show the problem, and will attach it to this post. Note that if you remove lines 56/57
oCaptionBar:attachToCalendar(o), ;
oDatePicker:attachToCalendar(o), ;
The program will close fine, although of course the controls will be non-responsive. Likewise, if you remove line 86 (QUIT) the program also closes fine.
A possible workaround might be a different way to exit the program, other than QUIT or returning from the main function, but I am unaware of any.
1) A CJDatePicker or CJCalendarCaptionBar is created, and the method oCaptionbar:attachToCalendar(oCalendar) or oDatePicker:attachToCalendar(oCalendar) is called. Note that it is the attachToCalendar part that is the problem. We can make the controls fine, it is only if they are attached that they cause the program to not close.
2) Closing the program with the QUIT command, instead of returning from the Main() function. Our program needs to close with QUIT because we need to be able to break out of the program from anywhere in it, even if we are nested several function calls deep.
Note that we are correctly calling oCaptionBar:detachFromCalendar() and oDatePicker:detachFromCalendar(), but that seems to have no affect. Also, disabling the data provider entirely seemed to have no affect.
I have modified Roger's codejock calendar demo to show the problem, and will attach it to this post. Note that if you remove lines 56/57
oCaptionBar:attachToCalendar(o), ;
oDatePicker:attachToCalendar(o), ;
The program will close fine, although of course the controls will be non-responsive. Likewise, if you remove line 86 (QUIT) the program also closes fine.
A possible workaround might be a different way to exit the program, other than QUIT or returning from the main function, but I am unaware of any.
- Attachments
-
- Calendar.zip
- A small sample to demonstrate the problem
- (25.1 KiB) Downloaded 1563 times
-
- Posts: 605
- Joined: Thu Jan 28, 2010 9:11 pm
- Location: Steven Point, Wisconsin USA
- Contact:
Re: Calendar causes app to stay resident
If it appears that you when you close the program normally it cleans up properly, how about if you put some the normal closing processing in an exit procedure like this:
I use this code to display and log a message whenever the program terminates, even my error without going through the normal exiting process. This might help when the Quit exit occurs.
Cliff.
Code: Select all
*+±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
*+
*+ EXIT PROCEDURE LoginStatus()
*+
*+ This procedure displays a warning message if the program exits without user being logged out
*+
*+±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
*+
EXIT PROCEDURE LoginStatus()
IF m->G_lIsLoggedIn
LB_Warning('FCA software did not log out user; contact IT','Program Error')
LB_LogSL('FCA software did not log out user: '+m->oper_init,'louterror.log')
ENDIF
RETURN
Cliff.
Re: Calendar causes app to stay resident
i saw SetMultipleResources. did someone get SetMultipleResources to work with Xbase++ ?Josh-Ferrus wrote:Hi, I am another developer at Ferrus who is working with this problem.
as i can say Xbase++ CreateObject is not "compatible" to XbpActiveXControl() so it will not work and like "build-in" Calender:Dialog ( complett data entry mask ) will crash.
Code: Select all
oAX := XbpActiveXControl(...)
oAX:create()
...
oCX := CreateObject(...)
...
oAX:Property := oCX -> Crash
this is IMHO while no activeX Connection is "close" like in your Demo. every CreateObject you have used must be "closed" and destroy() in reverse order.
DataProvider : why did you "load" all Records ? you just need to "load" those data which are "visible"
p.s. i did have work with Chris and Roger on Codejock Calender using Xbase++ and/or harbour to figure out SetMultipleResources or CalenderDialog works. after a while Codejock Calender seem me "to big" with all its futures and i wrote a Xbase++ Clone using XbpMultiCellGroup().
while i use my old Codejock Calender DBF ( Comix FPT) you should be able to use my Xbase++ Clone with your data. if someone like to have a full working Calender with some Source and DLL / LIB write me a PN or better come to Devcon 2012 and get it.
greetings by OHR
Jimmy
Jimmy
Re: Calendar causes app to stay resident
Josh
When I run your sample program it works fine.
Am I supposed to modify something to make sure that it stays resident after quitting the program?
Roger
When I run your sample program it works fine.
Am I supposed to modify something to make sure that it stays resident after quitting the program?
Roger
The eXpress train is coming - and it has more cars.
-
- Posts: 8
- Joined: Wed Aug 18, 2010 11:07 am
Re: Calendar causes app to stay resident
Roger:
I just re-downloaded the sample and built it to check, and, with no modifications, upon closing the app (with either the X, OK, or Cancel buttons) there is still a Calendar.exe process running. It is interesting that you're not getting the issue. All of the computers we tested this on are Windows 7, perhaps it's a Windows 7 specific issue? I can give it a try on one of the XP computers we have in the office. What version of windows are you on? And what version of CodeJock?
Auge_Ohr:
The SetMultipleResources line is commented out (with a note that it causes a runtime error). This is from the original sample, I did not modify it.
Cliff:
I tried to put my clean-up code (detachfrommodule() and destroy() calls) in an exit procedure, with no change in the issue.
Thanks for looking at the issue so far. We're still at a loss.
I just re-downloaded the sample and built it to check, and, with no modifications, upon closing the app (with either the X, OK, or Cancel buttons) there is still a Calendar.exe process running. It is interesting that you're not getting the issue. All of the computers we tested this on are Windows 7, perhaps it's a Windows 7 specific issue? I can give it a try on one of the XP computers we have in the office. What version of windows are you on? And what version of CodeJock?
Auge_Ohr:
The SetMultipleResources line is commented out (with a note that it causes a runtime error). This is from the original sample, I did not modify it.
Cliff:
I tried to put my clean-up code (detachfrommodule() and destroy() calls) in an exit procedure, with no change in the issue.
Thanks for looking at the issue so far. We're still at a loss.
Re: Calendar causes app to stay resident
Hi,
Maybe if you create a subfunction.
Maybe if you create a subfunction.
Code: Select all
Function startcalendar()
cResult := calendar()
if !cResult
quit
endif
return nil
function calendar()
// if you need to quit, close everything and return .F. else return .T.
...
Re: Calendar causes app to stay resident
I am using Codejock 13.0.0, Windows 7, Xbase++ 355, eXpress++ build 256 pre-release.
What version of eXpress++ are you using?
What version of eXpress++ are you using?
The eXpress train is coming - and it has more cars.