Divid Error?

[BRENT GARDNER]

Hi,

Program preformed illegal operation and will be shut down.

In windows 98, get error on title bar "Epirpe20". Says it caused a "Divide Error" in module EPIHTB3N.DLL at 017f:028b340b. Could this be a printer .dll? I had same problem yesterday and changed
some long integers to single percision and it seemed to work ok, until
today?

Hope someone knows how to fix this problem.

Thanks,

Brent

[Marco Pontello]

Could this be a printer .dll?

Yes, I think it's part of Epson drivers.

Bye!

[Michael Mattias]

That error is a divide by zero error, and while it can be caused by forces beyond your control (e.g. bad driver dll), it could also be caused by memory corruption due to a programming error somewhere prior to the call.

I'd check my own code for valid parameters being passed to whatever the external driver is before I'd go complaining to the driver publisher.

This...

I had same problem yesterday and changed some long integers to single percision and it seemed to work ok..

.. tells me that 'bad parameters' (programming error) is a genuine possibility.

[BRENT GARDNER]

Yes, It is a Epson printer Dll. Downloaded lastest driver which was 1998 and still have get error. So guess it's time for new printer. From
trial and error, discovered that :

Epson stylus color 740, gives error "divide error" if picture width/height is < 60%.

The picture I am using will look distorted if I resize to 60% rule. So, I
guess I'll have to tell users that they will have to get new printer or latest
drivers or size picture width/height = 60 %

[Michael Mattias]

If you know the DLL name, you can get the version number from it, and compare against what you need to run at < 60%.

i.e, your software can notify the user if his driver does not support his request BEFORE something bad (GPF) happens.

And ony because I am in a really good mood today...

' get version of of any file
FUNCTION FileVersionString(szFile AS ASCIIZ) AS STRING
  LOCAL major AS LONG, Minor AS LONG, Build AS LONG, SubBuild AS LONG
  LOCAL ResSize AS LONG
  LOCAL ffi  AS VS_FIXEDFILEINFO PTR
  LOCAL  ret AS LONG
  LOCAL Buffer AS STRING, DLLDate AS STRING

  Major=0: Minor = 0:  Build = 0

  ResSize = GetFileVersionInfoSize (szFile, ret)
  IF ResSize= 0 THEN
    FUNCTION = "No Version Info"
    EXIT FUNCTION
  END IF

  Buffer = SPACE$(ResSize)
  Ret =  GetFileVersionInfo(szFile, %NULL, ResSize, BYVAL STRPTR(Buffer))

' ** Read the VS_FIXEDFILEINFO info
  VerQueryValue BYVAL STRPTR(Buffer), "\", ffi, SIZEOF(@ffi)
  Major        = @ffi.dwProductVersionMs  \ &h10000
  Minor        = @ffi.dwProductVersionMs MOD &h10000
  Build        = @ffi.dwProductVersionLS MOD &h10000  ' this is for MY software which uses VERSION_MAJOR, VERSION_MINOR, 0, VERSION_BUILD under FILEVERSION
'  SubBuild     = @ffi.dwProductVersionLS \  &h10000
  ' combine

  FUNCTION = STR$(Major) & "." & TRIM$(STR$(Minor)) & "." & LTRIM$(STR$(Build))   ' & "." & LTRIM$(STR$(SubBuild))

END FUNCTION

Note: I do not use "build" and "sub-build" the way Windows does (I reverse them), so you'll have to modify this if your driver publisher (as he probably does) uses "standard" versioning.

MCM