>m.tcPassedString = CHRTRANC( m.tcPassedString, ; > m.tcBreakChar, ; > REPLICATE( lcX, LENC( m.tcBreakChar))) >>
>Fatal error: Exception code=C0000005 @ 24/10/2012 04:24:21 PM. Error log file: C:\Program Files (x86)\Common Files\Microsoft Shared\VFP\vfp9rerr.log > 调用自 - tokens line 3532 {c:\hrms\intl\msgsvc.prg c:\flexhrme\hrmfxp\msgsvc.fxp} > 调用自 - messaging.cookieswap line 16 {c:\flexhrme\progen.vct c:\flexhrme\progen.vct} > 调用自 - messaging.displaymessage line 41 {c:\flexhrme\progen.vct c:\flexhrme\progen.vct} > 调用自 - dmsgbox line 15 {c:\hrms\branches\4.1.1\hrm\prgs\dmsgbox.prg c:\flexhrme\hrmfxp\dmsgbox.fxp} > 调用自 - appentryerror line 122 {C:\flexhrme\prgs\shrmfman.prg c:\flexhrme\flexhrm.exe} > 调用自 - ON... line 0 { } > 调用自 - strtranc line 3682 {c:\hrms\intl\msgsvc.prg c:\flexhrme\hrmfxp\msgsvc.fxp} > 调用自 - messaging.cookieswap line 29 {c:\flexhrme\progen.vct c:\flexhrme\progen.vct} > 调用自 - messaging.displaymessage line 41 {c:\flexhrme\progen.vct c:\flexhrme\progen.vct} > 调用自 - dmsgbox line 15 {c:\hrms\branches\4.1.1\hrm\prgs\dmsgbox.prg c:\flexhrme\hrmfxp\dmsgbox.fxp} > 调用自 - duseview line 127 {C:\prglibe\duseview.prg duseview.fxp} > 调用自 - frmlogin.cbocompany.when line 24 {c:\flexhrme\forms\shrmssa.sct c:\flexhrme\forms\shrmssa.sct} > 调用自 - proapp.admintool_useraccess line 5 {c:\vpme9\vpmapp.vct c:\vpme9\vpmapp.vct} > 调用自 - proapp.runadmintool line 25 {c:\vpme9\vpmapp.vct c:\vpme9\vpmapp.vct} > 调用自 - vpmapp.runloginform line 3 {c:\vpme9\vpmapp.vct c:\vpme9\vpmapp.vct} > 调用自 - proapp.runloginform line 3 {c:\flexhrme\proapp.vct c:\flexhrme\proapp.vct} > 调用自 - proapp.startup line 132 {c:\flexhrme\proapp.vct c:\flexhrme\proapp.vct} > 调用自 - shrmfman line 103 {C:\flexhrme\prgs\shrmfman.prg c:\flexhrme\flexhrm.exe} > 调用自 - appexe line 1087 {C:\flexhrme\appexe.prg c:\flexhrme\flexexe.exe} > >Watch out for "upper-ASCII" characters (i.e. characters with ASC() values above 127) -- these are often used as "lead-in" characters for double-byte sequences in Asian language environments. One place you have to be especially careful about this is when dealing with ASCIIZ (NUL-byte terminated strings) strings you might use in interfacing with API calls -- if an "upper-ASCII" character occurs at the end, the NUL-terminator may get "eaten" in the interpretation process (sometimes you can kludge a fix by adding an extra NUL at the end).