Bugfixes BW version B40c.056 MergeProject: BaanIVc: # 7483 (VHNT2717): Installation of BW on Windows9x fails From: Source Manager Date: Fri, 10 Dec 1999 08:37:56 +0100 (MET) Release: BaanIVc Date: 1999/12/10 Script: MergeProject Project: VHNT2717 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) BW could not be installed on Windows95 Problem Description (Technical terms) Windows95 does not contain the msvcrt.dll This file is required by the benttool.dll, which is used during installation. Workaround Test Procedure Install BW on Windows95 Affected Executables Enduser installation Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 86774 449787 30 455893, 464236 470321, 474788, 475936 MergeProject: BaanIVc: # 7857 (VHNT2917): BW4: Scopus 88727: crash in getChainedKeyboardFocusWidget From: Source Manager Date: Fri, 28 Jan 2000 16:55:58 +0100 (MET) Release: BaanIVc Date: 2000/01/28 Script: MergeProject Project: VHNT2917 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) bw crashes while starting up. the dumped stack trace has getChainedKeyboardFocusWidget on top. More precisely, the stack dump looks like this: Message Exception C0000005 (Access violation) TsWidgetRec::getChainedKeyboardFocusWidget+C (1:000cc7c9) TsMSWindowImplementation::computeFocusWindow+26 (1:0003d2d2) TsMSKeyboardFocus::computeTsFocusWindow+23 (1:0003f652) TsMSKeyboardFocus::setMSFocusWindow+10 (1:0003f62d) TsMSKeyboardFocus::setMSFocusWindow+3D (1:0003f602) TsMSKeyboardFocus::processWM_KILLFOCUS+66 (1:0003f5a6) TsMSWindowImplementation::processWM_OVERLOADED+14 (1:0003e2a1) TsMSMessageWM_KILLFOCUS::messageProcedure+F (1:00036f5e) TsMSWindowMessage::sendMessage+15 (1:00020e65) TsMSWindowImplementation::superclassWindowProc+40 (1:0003eca8) 1:000009d0 1:00000982 1:000153a3 1:000008d2 StartupLogo::windowProc+B9 (1:00006723) StartupLogo::wndProc+45 (1:00006664) 1:000009d0 1:00000982 1:000153a3 TsMSWindowImplementation::MSUnrealize+27 (1:0002853d) TsMSShellWindow::unrealize+C (1:000ee19c) TsMSShellWindow::Destructor::operator()+10 (1:000ee180) TsWindow::destroy+18 (1:000ccf98) TsWidgetRec::executeDestruction+F (1:000cc5f4) TsWindowWorkList::worklist_proc+1A (1:000cd13a) TsWorkList::apply+5D (1:000a65bd) TsWindowWorkList::apply+26 (1:000cd116) TsWidgetRec::executeDestructionList+14 (1:000cd0d4) TsObjectClassRec::WorkProcData::operator()+13 (1:000a6e83) TsObjectClassRec::WorkProcData::call_all+11 (1:000a5db0) TsObjectClassRec::callDestroyWorkProcs+E (1:000a66de) TsObjectRec::executeDestructionList+2A (1:000a46bb) TsObjectRec::TsDestroyPostponer::postponed_proc Problem Description (Technical terms) Very early after starting BW, some widget is destroyed and the Startuplogo is activated (WM_ACTIVATE message). This causes a KILLFOCUS message to the window which is being destroyed, with the HWND of the StartupLogo as the GetFocus window. The GWL_USERDATA of this window is taken, and interpreted as a pointer to an MSWindowImplementation, but in fact it is a pointer to a StartupLogo. Hence the crash some time later. Workaround none Test Procedure in the bw config, specifiy ttaad4100 as the startup session. Affected Executables bw Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 88727 xxx(Scopus is down) 20 MergeProject: BaanIVc: # 8447 (VHNT3232): BW alpha build From: Source Manager Date: Thu, 23 Mar 2000 12:04:11 +0100 (MET) Release: BaanIVc Date: 2000/03/23 Script: MergeProject Project: VHNT3232 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) Still compilation problems on NT alpha. Problem Description (Technical terms) VS can not handle generated dsp files correctly because of existance of Japanese configurtion. Nightly build is needed to detect build problems in time. Workaround Test Procedure Build on NT alpha. Affected Executables BW Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 8291 (VHNT3218): BW configration From: Source Manager Date: Fri, 3 Mar 2000 09:52:25 +0100 (MET) Release: BaanIVc Date: 2000/03/03 Script: MergeProject Project: VHNT3218 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) BW did not compile anymore. Problem Description (Technical terms) Wrong syntax in makefile al.mak . Workaround Test Procedure Affected Executables BW Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 8286 (VHNT3217): Changed option username to giveaway in BW From: Source Manager Date: Thu, 2 Mar 2000 17:08:08 +0100 (MET) Release: BaanIVc Date: 2000/03/02 Script: MergeProject Project: VHNT3217 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) The BW option -username was causing some problems with the already existing option -user in BW for Verdi Problem Description (Technical terms) Workaround Test Procedure Affected Executables Baan Nt Managers BW Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 8282 (VHNT3208): NT alpha BW From: Source Manager Date: Thu, 2 Mar 2000 16:01:21 +0100 (MET) Release: BaanIVc Date: 2000/03/02 Script: MergeProject Project: VHNT3208 Created on: BaanIVc Type: porting specific change Problem: Problem Description (Customer terms) BW did not compile on alpha. Problem Description (Technical terms) Makefiles were not up to date for alpha. Workaround Test Procedure Affected Executables BW Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 8232 (VHNT2918): Add username option to bw From: Source Manager Date: Mon, 28 Feb 2000 09:45:49 +0100 (MET) Release: BaanIVc Date: 2000/02/28 Script: MergeProject Project: VHNT2918 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) It is not possible to give away the credentials (username and password) to log in Baan to somebody else, without telling him/her your password. This is also a problem for the Job Daemon on Windows NT: When starting the Job Daemon it asks for a password, because the Logon of the Job Daemon service is different then the user who saved the password information into the jobd.bwc file. BW does not allow to re-use the encrypted password information by somebody else then the person who saved this password information. Problem Description (Technical terms) The password is encrypted with the current user. The current user is the user currently logged in Windows. Workaround Tell the password. Test Procedure Log in Windows NT as user "baan" Start bw as follows: bw.exe /config /username=kvddool jobd.bwc Turn on "Save Password", and fill in the password field. Press Save As, and save this configuration to test.bwc. Open test.bwc now: bw.exe /config test.bwc The password field is greyed out now, because only user "kvddool" is allowed now to use this password information. Log in Windows NT as user "kvddool" Start bw as follows: bw.exe test.bwc Now, you will be logged in Baan, without being prompted for the password. Affected Executables bw.exe bwconfig.dll Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 36946 817182 30 TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 8106 (VHNT3110): Scopus 37594: BW4 crashes in setTsFocusWindow From: Source Manager Date: Wed, 16 Feb 2000 07:58:15 +0100 (MET) Release: BaanIVc Date: 2000/02/16 Script: MergeProject Project: VHNT3110 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) BW4 crashes Problem Description (Technical terms) BW4 crashes, and the dumped stack trace is as follows: Stack Trace from Visual Studio: ======================== 00000000() USER32! 77e727fe() USER32! 77e72889() TsMSWindowMessage::callWindowProc(HWND__ * 0x00000000, long (HWND__ *, unsigned int, unsigned int, long)* 0x00000000) line 99 TsMSWindowImplementation::callWindowProc(long (HWND__ *, unsigned int, unsigned int, long)* 0x00000000, const TsMSWindowMessage & {...}) line 837 TsMSWindowImplementation::processBaseclass(const TsMSWindowMessage & {...}) line 621 TsMSWindowImplementation::processAltWM_OVERLOADED(const TsMSMessageWM_KILLFOCUS & {...}) line 780 TsMSMessageWM_KILLFOCUS::altMessageProcedure(TsMSWindowImplementation & {...}, const TsMSWindowMessage & {...}) line 337 + 15 bytes TsMSWindowMessage::sendMessage(TsMSWindowImplementation & {...}) line 128 + 14 bytes TsMSWindowImplementation::sendMessage(const TsMSWindowMessage & {...}) line 1139 TsMSWindowImplementation::killFocus(TsMSWindowImplementation & {...}) line 1205 TsMSKeyboardFocus::setTsFocusWindow(TsMSWindowImplementation & {...}) line 145 TsMSKeyboardFocus::computeTsFocusWindow() line 91 + 47 bytes TsMSKeyboardFocus::setMSFocusWindow(TsMSWindowImplementation & {...}) line 82 TsMSKeyboardFocus::processWM_SETFOCUS(TsMSWindowImplementation & {...}, const TsMSMessageWM_SETFOCUS & {...}) line 51 + 9 bytes TsMSWindowImplementation::processWM_OVERLOADED(const TsMSMessageWM_SETFOCUS & {...}) line 976 + 13 bytes TsMSMessageWM_SETFOCUS::messageProcedure(TsMSWindowImplementation & {...}, const TsMSWindowMessage & {...}) line 260 + 15 bytes TsMSWindowMessage::sendMessage(TsMSWindowImplementation & {...}) line 128 + 14 bytes TsMSWindowImplementation::superclassWindowProc(HWND__ * 0x0034072e, unsigned int 7, unsigned int 0, long 0) line 1115 + 46 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() USER32! 77e727fe() USER32! 77e72889() TsMSWindowMessage::callWindowProc(HWND__ * 0x0034072e, long (HWND__ *, unsigned int, unsigned int, long)* 0x77e718ad) line 99 TsMSWindowImplementation::callWindowProc(long (HWND__ *, unsigned int, unsigned int, long)* 0x77e718ad, const TsMSWindowMessage & {...}) line 837 TsMSWindowImplementation::processBaseclass(const TsMSWindowMessage & {...}) line 621 TsMSWindowImplementation::processWM_OVERLOADED(const TsMSMessageWM_ACTIVATE & {...}) line 605 TsMSShellWindowImplementation::processWM_OVERLOADED(const TsMSMessageWM_ACTIVATE & {...}) line 478 + 12 bytes TsMSMessageWM_ACTIVATE::messageProcedure(TsMSWindowImplementation & {...}, const TsMSWindowMessage & {...}) line 260 + 21 bytes TsMSWindowMessage::sendMessage(TsMSWindowImplementation & {...}) line 128 + 14 bytes TsMSWindowImplementation::superclassWindowProc(HWND__ * 0x0034072e, unsigned int 6, unsigned int 1, long 0) line 1115 + 46 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() TsMSWindowImplementation::MSRaise() line 172 TsMSShellWindow::raise() line 408 TsWidgetRec::realize() line 220 TsCompositeRec::doRealize() line 169 TsWidgetRec::topRealize() line 176 TsMSToolkit::realizeWidget(_TsWidget_Dummy_ * 0x01311a50) line 284 TsRealizeWidget(_TsWidget_Dummy_ * 0x01311a50) line 334 DmRealizeMWindow(dm_object_entry * 0x01311e40) line 756 + 9 bytes DmSetState(int 1, dm_attribute_struct * 0x00535b34, dm_proc_entry * 0x01245a4c, dm_object_entry * 0x01323718, int 0, Arg * 0x0012fbc4, unsigned long * 0x0012fcc8, DmTstorage * 0x0012fac4) line 3303 + 9 bytes DmProcessArgList(int 1, dm_proc_entry * 0x01245a4c, dm_object_entry * 0x01323718, Arg * 0x0012fbc4, unsigned long * 0x0012fcc8, unsigned long 24, DmTstorage * 0x0012fac4, unsigned int 24) line 1040 + 35 bytes DmChangeWidgetProc(dm_proc_entry * 0x01245a4c, dm_object_entry * 0x01323718) line 715 + 41 bytes DmChangeMenuObject(dm_proc_entry * 0x01245a4c, dm_object_entry * 0x01323718) line 991 + 13 bytes DmChangeWinObject() line 272 + 14 bytes DmRequestHandler() line 310 + 18 bytes DmRequestInputHandler(void * 0x00000000, int * 0x0012fd78, _TsInputId_Dummy_ * 0x01110d0c) line 261 + 5 bytes TsInputIdRec::callCallback(void * 0x00549f00 _stream_pool) line 88 + 26 bytes TsMSInputIdRec::streamCallbackProc(void * 0x00549f00 _stream_pool, int 1, int 0, long 17894668) line 74 SocketData::callCallback(int 1, int 0) line 262 + 28 bytes SocketData::processStreamData() line 992 SocketData::processIncomingData(int 1, unsigned int 356) line 1074 + 8 bytes SocketData::windowProc(HWND__ * 0x00400530, unsigned int 1280, unsigned int 356, long 1) line 1149 USER32! 77e71820() Analysis: During the TsMSKeyboardFocus::setTsFocusWindow() call, the old value of Ts_focus_window is saved in wndLoseFocus, and if it is nonzero, then wndLoseFocus->killFocus() is called. However, wndLoseFocus points to a window which is already deleted. Most of time no harm is done, sometimes it causes a crash. Workaround None Test Procedure see Scopus defect 37594 Affected Executables bw.exe Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 37594 809110,480354 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: BaanIVc: # 7959 (VHNT3022): bw40.bld From: Source Manager Date: Fri, 4 Feb 2000 12:16:13 +0100 (MET) Release: BaanIVc Date: 2000/02/04 Script: MergeProject Project: VHNT3022 Created on: BaanIVc Type: porting specific change Problem: Problem Description (Customer terms) BW is not in nightly build. Problem Description (Technical terms) BW has to be build in separate view because of different compilation flags. In build_all.bld a new item bw40.bld is added now. The .mak files are converted to dsw/dsp files. When a .mak is modified the dsw/dsp files should be generated again. Workaround Test Procedure Nightly build Affected Executables BW Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable)