annoying application error in 9.10.04

Home Forums Multi-Edit Support annoying application error in 9.10.04

Viewing 10 posts - 16 through 25 (of 25 total)
  • Author
  • #5991

    This exact error popped up when I was trying to open a file found and listed in a still searching Windows XP Pro search window.

    The file opened, and I got this same error.

    I hope that helps track it down.



    I am also getting these errors. Everything seems to work (if you ignore the error dialogs) although shutting down the editor is a pain.

    This is on a multi-monitor WinXP pro system. 3.2Ghz P4, 2Gig ram.

    If it matters I often run (and add files to) multi-edit from the command line.


    I’m getting the same error – has support responded with a fix yet?


    I’ve never seen the problem happen until just recently and that only happened after I recompiled Multi-Edit using Delphi 2006 which has a new memory manager that is less forgiving of memory issues.

    I have this on my list of things to get fixed before the next release. I still haven’t figured out exactly what the conditions are that cause this issue but at least now I can get it to happen frequently enough that I believe I can figure out the problem.

    Thanks to everyone that has reported their setup information. This will help me to know where to start looking.


    One thing that can cause an internal buffer overflow in Multi-Edit is if one of the global history string variables is longer than around 990 characters and it gets used in a dialog box. Normally file path/name length is limited to 259 chars on Windows, but there was one instance when I was doing a Wildcard Tag Scan and strung together a lot of file names that exceeded this limit (because I wasn’t savvy enough to use a wildcard).

    Here’s a simple program that will list all global string variables longer than 950. The output will go to window MSG-2.LOG. If any of the global variable names listed have the word HISTORY in it, it could be a problem.

    void global950()
    int gType;
    str gv[ 32 ];
    str gs[max_line_length];

    gv = First_Global( gType );
    while ( gv != ” )
    if ( !gType ){
    gs = Global_Str(gv);
    if (svl(gs) > 950){
    Pad_Str(gv, 32, " ");
    DebugLog(2,"gv",gv+" "+gs);
    gv = Next_Global( gType );

    (Dan refer to Deley Discussions “dialog.s buffer overflow”)


    OK folks, I’ve been trying to track down this issue and I have found out a few things.

    By chance do any of you that have this problem use Window Blinds to skin your applications and allow it to skin Multi-Edit?

    I have found that if I use Window Blinds and I open the Explorer style dialog, when I shutdown Multi-Edit I get the error described here. If I disable Window Blinds from skinning Multi-Edit, then I have no trouble shutting down Multi-Edit. I haven’t figured out exactly why error is happening as the code in the File Prompt is code from a third party component library that we are using and I haven’t gotten into checking their code yet.


    I do NOT use Window Blinds.

    I have experienced this error by opening files from inside MS Explore, not editing anything (look and see) and closing ME.

    A Windows connection is assured.

    Incidentally, I don’t THINK there are any file names that exceed DOS length limits involved in my set up.

    Good luck, and good hunting.



    By the way…

    I apparently did not have the ME AutoSave system set up properly.

    the BAK and TMP directories did not exist, but I had requested an autosave, and a backup of the original file the first time only.

    I recently fixed that. Could there be a relationship with this other error?



    I also get this error and it start after I upgrade to a new laptop that has a dual core chip set. The laptop also has 2GIGs of RAM. I can general produce the error just me open and closing MEW repeatly. With no files being open by MEW.

    Just thought I throw my observations in.



    I am not sure if this problem is related to: … highlight=

    Although this was a problem purely from having 2 physical CPU’s and was solved using a program that sets the affinity.


Viewing 10 posts - 16 through 25 (of 25 total)
  • You must be logged in to reply to this topic.