Version 13.05 unstable ?

[TimStone]

Last night I released an update to my program using Version 13.05 with xHarbour ( .com Aug 2010 ). Since then I have been drowning in calls from people with major problems. I finally did a build with 13.04 and reposted so hopefully that will resolve my problems.

The main issue here is lockups, and especially in multi-user situations. The program just locks up ! These are multi-user situations and if one machine locks up it locks up the network apparently.

We had a problem with the message bar causing a lockup, and there was a fix for that. Well it would appear this problem is far more universal.

Here are the things we can't do : 1) We can't make a small sample because its dying in the more comprehensive processes, and 2) We can't test on a single user machine and say its OK because its happening in networks.

Other symptoms are that the video display is acting up. The bitmaps are disappearing, dialogs turn into lines, etc.

SO ... I need to use a process of elimination to find the problem, and the only thing different between what worked and what doesn't is we built this with 13.05 not 13.04 ! There were no new libraries introduced, no new functionality activated ... I just used 13.05 instead of 13.04.

We now know we had to manually patch xBrowse and tmsgitm. Also we had to add hb_parns to the MAIN( ) for xHarbour.

I believe the only way to get this working is for those who made changes between 13.04 and 13.05 to review what they did ! Only by looking at the changes will we find the source of the problems.

Of course, maybe some of you have a different experience. The problematic build is with xHarbour( .com Aug 2010 ), FWH 13.05 ... so if anyone else is using those tools and does not have problems, please let me know.


Tim

[Antonio Linares]

Tim,

The dissappearing bitmaps, bad image, etc. is usually the result of resources leaking. So it could be that a change in FWH 13.05 is leaking resources (GDI objects). We can check this calling SetResDebug( .T. ) at the beginning of the app, and CheckRes() at the end. You could run it for a while, then exit and review a created log file. If it is a GDI resources problem, it will get confirmed there:

http://wiki.fivetechsoft.com/doku.php?id=fivewin_function_setresdebug

http://wiki.fivetechsoft.com/doku.php?id=fivewin_function_checkres

On a second idea that comes to my mind, consider this: you have not changed anything, but FWH has grown, and this could reveal hidden problems in xharbour. It is not the same app, it is larger and manages more symbols internally. It is just a guess of what may it be happening based on your own comments as I don't have it here to test it myself.

[Antonio Linares]

Tim,

Did you change from TActiveX to THActiveX in your app ?

When the app crashes, are codejock OLE controls being used ?

[Antonio Linares]

This is the complete list of changed files from FWH 13.04 to 13.05:

As you can see, only three low level files have been modified. One specifically related to ActiveX:

fwh/source/function/c5cnew.c
fwh/source/winapi/caldll32.c
fwh/source/internal/actx.cpp

the complete list:

fwh/doall.bat
fwh/fwhx.mak
fwh/fw64.mak
fwh/mfwhg.bat
fwh/include/hbcompat.ch
fwh/include/fwsqlcmd.ch
fwh/include/dialog.ch
fwh/include/colors.ch
fwh/include/xbrowse.ch
fwh/include/print.ch
fwh/include/fivewin.ch
fwh/include/ribbon.ch
fwh/include/adodef.ch
fwh/include/ado.ch
fwh/fwh.mak
fwh/mfwhx.bat
fwh/source/function/fwdecode.prg
fwh/source/function/harbour.prg
fwh/source/function/xbrowser.prg
fwh/source/function/prv2pdf.prg
fwh/source/function/valblank.prg
fwh/source/function/olefuncs.prg
fwh/source/function/valtostr.prg
fwh/source/function/c5cnew.c
fwh/source/winapi/caldll32.c
fwh/source/internal/actx.cpp
fwh/source/classes/datarow.prg
fwh/source/classes/tmsgitem.prg
fwh/source/classes/xbrowse.prg
fwh/source/classes/activex.prg
fwh/source/classes/database.prg
fwh/source/classes/mdichild.prg
fwh/source/classes/window.prg
fwh/source/classes/btnbmp.prg
fwh/source/classes/printer.prg
fwh/source/classes/dialog.prg
fwh/source/classes/tribbon.prg
fwh/source/classes/trbgroup.prg
fwh/source/classes/combobox.prg
fwh/source/classes/trbtn.prg
fwh/source/classes/metropnl.prg
fwh/source/classes/control.prg
fwh/source/classes/xbrcode.prg
fwh/fwhg.mak
fwh/samples/olebrow.prg
fwh/samples/dlgbrush.prg
fwh/samples/access.prg
fwh/samples/gmail.prg
fwh/samples/speak.prg
fwh/samples/access2.prg
fwh/samples/outlook.prg
fwh/samples/buildh.bat
fwh/samples/buildx.bat
fwh/samples/gianni.prg
fwh/samples/buildgl.bat
fwh/samples/ribbon3.prg
fwh/samples/combos.prg
fwh/samples/buildhm.bat
fwh/samples/fivedbu.prg
fwh/samples/xbrgen.prg
fwh/samples/buildxm.bat
fwh/samples/buildhdp.bat
fwh/samples/buildhd.bat
fwh/samples/build64x.bat
fwh/samples/build64.bat
fwh/samples/buildh32.bat
fwh/samples/rbdesign.prg
fwh/samples/fivedbu.rc
fwh/samples/buildxd.bat
fwh/samples/buildg.bat
fwh/mfwh.bat
fwh/install/fwh.iss
fwh/install/fwh64.iss
fwh/mfw64.bat
fwh/whatsnew.txt

[elvira]

Friends,

Also, this build is not stable yet. Changes in TWindow/Tcontrol?.

thanks.

[Antonio Linares]

The three low level files changes are not important (two removed functions, and DeleteFile() renamed as FWDeleteFile()), except on ActiveX where ActXEvents() have been modified and this is related to the routing of the activex events, thats why I think that when Tim apps experiences problems could it be related with the codejock and the new activex changes.

In window.prg there are some minor additions, nothing that could affect at all to the app. Nothing has changed there.

I keep reviewing all the changes and reporting my findings...

[Antonio Linares]

in control.prg we have replaced a nil with self and added and extra comparison here:

if ::oWnd:oMenu != nil .and. ::oWnd:oMenu:oAccTable != nil

IMO, nothing that could make TControl unstable

[TimStone]

Antonio,

I have been swamped so I couldn't respond sooner. Hopefully I have resolved the problem for now by using 13.04 ... but a weakness in my updater made it problematic to get the reverted version to my clients.

You mentioned using the Free version of xHarbour in another thread. That isn't available to use with xHarbour.com ....

I may be frozen at 13.04 for that and use ongoing versions for my Harbour/MSVC ... once I can confirm it is stable I can put that out. Doing so before summer vacations is a nightmare, however, so I may have to wait.

The problem didn't show up in the Codejock section ... maybe because no one got that far. It was all with standard dialogs and buttons ( not a ribbon bar, but yes to a button bar ). It also appeared to be with the networking ( ADS ... same drivers and .DLLs as always ).

All I can say is it was a Tsunami of errors all over the place, and nothing consistent. I'll start tearing into it in a couple of hours.

BTW, I'm not sure what you ment about changing the tAXCTIVEx module.

Tim

[Antonio Linares]

Tim,

Please check if there are error.log files so we can check what kind of errors are going on.

I am going to check resources consume with FiveDBU which uses dialogboxes, browses and buttonbars

[Antonio Linares]

Tim,

If you revert back to your previous app, there are no errors at all ?

This is obvious, but have you checked with an antivirus ?

[Antonio Linares]

I have added:

SetResDebug( .T. )

to the beginning of samples/fivedbu.prg and:

CheckRes()

as the last line before return nil. And after opening many child windows, using browses, dialogboxes and reports preview, this is all I got inside checkres.txt

13/06/2013 23:42:08: BRUSH,-1257235400,TCOMBOBOX:SETCOLOR(2540)->TCOMBOBOX:NEW(207)->TPREVIEW:BUILDWINDOW(511)->TPREVIEW:NEW(136)->RPREVIEW(1634)->(b)TREPORT_NEW(187)->TREPORT:ACTIVATE(883)->TXBROWSE:REPORT(7005)->(b)EDIT(957)->TBTNBMP:CLICK(466)->TBTNBMP:LBUTTONUP(657)->TCONTROL:HANDLEEVENT(1719)->TBTNBMP:HANDLEEVENT(1446)->_FWH(3180)->WINRUN(0)->TMDIFRAME:ACTIVATE(993)->MAIN(70)

13/06/2013 23:42:08: ====================================================================================================

Just one left brush, that of course I am going to search and fix. But one single brush never ever would hang an app or consume all GDI resources. So there must be something else in the code that your app uses.

[TimStone]

Antonio,

Here is what I know for sure.

1) Built with 13.04, I have no problems. All of the code is 100% the same EXCEPT I was able to remove the modified tMsgItem and xBrowse .prg files which were needed for 13.05.
2) Built with 13.05, the errors do not appear on a stand along single user machine, but they do seem to occur when using a network ( ADS ).
3) I did not have the problem here because I was not testing on a network.
4) I probably had 35 businesses go down this morning because of this. They are all separate locations, and have no virus reports ( all are secure ). Once I put on the build with 13.04 all reverted to normal operations and were fine. I only changed the .exe file, no re-indexing, or anything else.
5) There were no errors thrown. The screens seemed to dissolve and the computers simply locked up. Nothing could get them to work in the program.

Tim

[TimStone]

Also, I did do the debug check and sent you the res file by email

Tim

[Antonio Linares]

Tim,

So do you say that everything is exactly the same (including the xharbour build) and just FWH changed ?

Are you 100% sure about that ? thanks

[TimStone]

Antonio,

With 13.04 I use the combobox modified code we had.

With 13.05, you had me insert the language for parns( ), and I had to modify the the tMsgItem and xBrowse .prgs as noted on other threads about 13.05. I use the exact same script in both cases and there are NO other differences.

Tim