News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

AddIn support

Started by Biterider, May 07, 2005, 06:06:23 PM

Previous topic - Next topic

KetilO

Hi Biterider

Can there be some confusion on long / short filenames or maybe the path?

KetilO

Biterider

Hi KetilO
I think I've found the pattern of the problem. If I open a file that is part of a project and it is located in the same directory as the rap file (in the project tree it is NOT indicated with ..\..\) then and only then, the wParam parameter of the AIM_PARSEDONE message contains the negated handle of the MDI child. All other files in different directories behave normal, returning the file ID in wParam. Perhaps this helps.
Files that are not in the project, returns the negated MDI child handle as it should be.

Biterider

Biterider

Hi KetilO
I want to tell you about some strange thing that happens using the GetFileNameFromID procedure. If I provide a an invalid argument, the function returns NULL and in some cases after the function returns, RadASM crashes. If I remove the call to this function all returns to normality. Can check this code?

Regards,

Biterider

KetilO

Hi

The buffer for converting the FileID in GetFileNameFromID was too small, only 8 byes.

I still cant find anything wrong with the AIM_PARSEDONE. All the projects I have tested are OK.

It might help if you post the full path and what it looks like in the .rap file.

KetilO


[attachment deleted by admin]

Biterider

Hi KetilO
I tested the new procedure and all works OK. About the inverted Handle issue, I attached a picture of the project tree. All files without the ..\.. have the mentioned problem. The full path for these files is "C:\Masm32\ObjAsm32\Projects\RA_OA32AddIn\xxx"

Biterider

[attachment deleted by admin]

Biterider

Hi KetilO
I tried to reproduce the AIM_PARSEDONE problem on another machine (also XP) with exactly the same path and it didn't happen. Then, I copied the whole RadASM to the new machine to be sure that the DLLs are the same and the problem didn't appear like before. Returning to the first machine, the retuning value in wParam was inverted. I have no explanation for this behaviour...

Biterider

KetilO

Hi Biterider

My guess is that RadASM is set to run in some copatibility mode on that machine. The machine reports short filenames while RadASM uses long filenames.

KetilO

Biterider

Hi KetilO
I checked if RA is runningin some compatibility mode but it is not the case.
I retrieved the MDI Client window text from from one of the files with the problem and it returns a full qualified path (C:\Masm32\ObjAsm32\Projects\RA_OA32AddIn\RA_OA32_AddIn.inc). Is there a way to output he string you are using to evaluate if the file is a project file or not?
For the moment y write a bypass that works for me

        ...
        mov ecx, [esi].pProcs
        invoke GetFileNameFromIDPto ptr [ecx].ADDINPROCS.lpGetFileNameFromID, wParam
        mov ecx, [esi].pHandles
        m2m hChild, [ecx].ADDINHANDLES.hMdiCld
        invoke GetWindowLong, hChild, GWL_ID
        .if (eax >= ID_FIRSTCHILD) &&  (eax <= ID_LASTCHILD)
          invoke GetWindowText, hChild, addr bBuffer1, sizeof bBuffer1
          invoke GetFullPathName, addr bBuffer1, sizeof bBuffer1, addr bBuffer1, NULL
          invoke GetLongPathName, addr bBuffer1, addr bBuffer2, sizeof bBuffer2
          ...


Even if I have the bypass, I think we have to see what is going wrong.

Biterider

Mark Jones

Hi, I don't suppose Jeremy Collake or Milos Tziotas still frequent the boards? I tried to use the AsmVars plugin today and it complains of masm32rt.inc:

Quote from: AsmVars.dll
------------------------------------------------------------------
AsmVars v1.00a, (c)2001 Jeremy Collake
------------------------------------------------------------------

==== Pass 1 of 4
Processing file: C:\masm32\RadASM\Helios\TIMERS~1\RANDCR~1\rng.asm
Including file: masm32rt.inc
Processing file: masm32rt.inc - ERROR OPENING!
==== Pass 2 of 4
Processing file: C:\masm32\RadASM\Helios\TIMERS~1\RANDCR~1\rng.asm
Processing file: masm32rt.inc - ERROR OPENING!
==== Pass 3 of 4
Processing file: C:\masm32\RadASM\Helios\TIMERS~1\RANDCR~1\rng.asm
Processing file: masm32rt.inc - ERROR OPENING!
==== Pass 4 of 4
Processing file: C:\masm32\RadASM\Helios\TIMERS~1\RANDCR~1\rng.asm
Processing file: masm32rt.inc - ERROR OPENING!
Total lines: 442

------------------------------------------------------------------
UNREFERENCED VARIABLES
------------------------------------------------------------------

Total unreferenced variables: 0
All done.

I did however find a 1.01 version of asmvars.exe at http://www.bitsum.com/ (past the middle.) So I made a .CMD file to run it:


@echo off
%1\asmvars.exe %2
echo.
pause


and placed all the files in \AddIns. Then I added a tools menu shortcut to it with this command:


$D\asmvars.cmd,$D,2


And it works... but this (newer?) version behaves no better. In fact after some testing it reported a few labels and vars which WERE in use. :dazzled:

Is it anything I'm doing wrong? Thanks for reading. :bg
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

KetilO

Hi Mark Jones

The problem is that asmvars needs full path to included files like:
include C:\masm32\Include\masm32rt.inc

However you do not need / want to process theese files as they usually dont contain any variables, locals or procedures.
Processing huge files like windows.inc is just a waste of time.

KetilO

Mark Jones

Hi KetilO, that makes sense, thanks. I was just concerned that maybe the errors might indicate other problems. But with further investigation, it seems like the 1.01 release was simply buggy. Too bad development stopped, it's a great tool.

Quickly I have a question about AIM_MAKEDONE, it seems that this message is passed to an Add-In twice, once at resource compilation and again after linking. Is there any way to differentiate the two? :U
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

KetilO

You can pair the AIM_MAKEBEGIN and AIM_MAKEDONE and then use the lParam of AIM_MAKEBEGIN to find out what was done.

KetilO

Mark Jones

Excellent, thanks. Now I've copied the current hEdit text into a buffer, modified it, and pasted it back. This works fine, but is there a way to create an "undo" entry, so that the changes can be undone? :bg
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

KetilO

Hi Mark Jones

Undo is automatic on WM_CLEAR, WM_CUT and WM_PASTE
On EM_REPLACESEL wParam must be TRUE.
On WM_SETTEXT there is no undo.

KetilO

Biterider

Hi KetilO
I'm adding new functionality to the OA32 Addin. Doing so, i need a modeless dialog to be shown.
My first attempt was using CreateDialogParam and i noticed that some messages were not processed due to the lack if invoking IsDialogMessage for that window.
My next step was trying to call ModelessDialog exported by the ADDINPROCS without luck. A short look at the source of MdiRadAsm.asm showed that you are invoking IsDialogMessage for only a few windows.

My request is, if it is possible to add a mechanism to add more window handles to be checked by IsDialogMessage in the main messageloop?
Maybe you can add the handle in a list when ModelessDialog is called and remove it when DestroyWindow is called. A DestroyModalDialog proc must be suppied in the ADDINPROCS struct.

Regards,

Biterider