News:

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

about EM_GETMODIFY message

Started by vega, June 18, 2007, 12:30:42 PM

Previous topic - Next topic

vega

Is it unusable for RichEdit?
Only suitable for an Edit Control?

in my test, this code is well executed.
 
  INVOKE  SendMessage, hEdit, EM_GETMODIFY, 0, 0


but, this code is'nt executed. it caused error.

  INVOKE  SendMessage, hRichEdit, EM_GETMODIFY, 0, 0

What's wrong?

   - asm.Student -


Tedd

EM_GETMODIFY and EM_SETMODIFY are supported in Rich-Edit, so there's no problem there.
Maybe there is a problem with your hRichEdit value - are you sure it's correct?
No snowflake in an avalanche feels responsible.

vega

Thanks, Tedd~
I can't find any reason for my problem.
This is a relation codes about it.


***********************************

   Begin_of_WinProc_Procedure


      ;
   .IF uMsg == WM_CREATE
      JMP  START_PROCESS
   .ENDIF
      ;


   START_PROCESS:
      INVOKE  LoadLibrary, ADDR RichEditDLL
      MOV  hRichEditDLL, EAX
      INVOKE  GetClientRect, hWin, ADDR Rect
      MOV  EAX, Rect.right
      MOV  EBX, Rect.bottom
     
      INVOKE  RichEdit, 0, 0, EAX, EBX, hWin, 900
      MOV  hRichEdit, EAX
     
      ;Create_Intercept_Procedure_of_RichEdit_with  RichEditProc
      INVOKE  SetWindowLong, hRichEdit, GWL_WNDPROC, ADDR RichEditProc
      MOV  RichEditAddress, EAX
   Jump_to  NEW_FILE_PROCESS
   ;



      NEW_FILE_PROCESS:
         CALL  MODIFICATION_FLAG_CHECK_ROUTINE
         .IF EAX == CANCEL
            Jump_to  DEFAULT_MESSAGE_PROCESS
         .ENDIF 
         ;
         ;
      Jump_to  DEFAULT_MESSAGE_PROCESS



      OPEN_FILE_PROCESS:
         CALL  MODIFICATION_FLAG_CHECK_ROUTINE
         .IF EAX == CANCEL
            Jump_to  DEFAULT_MESSAGE_PROCESS
         .ENDIF 
         ;
         ;
      Jump_to  DEFAULT_MESSAGE_PROCESS

         ;

      EXIT_PROCESS:   
         CALL  MODIFICATION_FLAG_CHECK_ROUTINE
         .IF EAX == CANCEL
            Jump_to  DEFAULT_MESSAGE_PROCESS
         .ENDIF
         ;
           
     
   End_of_WinProc_Procedure




   ;
   MODIFICATION_FLAG_CHECK_ROUTINE:
      INVOKE  SendMessage, hRichEdit, EM_GETMODIFY, 0, 0
      .IF EAX == TRUE
         Rem: if the Contents in an RichEdit.control has been modified,
         JMP  WORKING_FILE_SAVE_ROUTINE
      .ENDIF
      RET


   ;
   RichClass  BYTE  "RICHEDIT", 00H
   ;
   RichEdit   PROC  x:DWORD, y:DWORD, wd:DWORD, ht:DWORD, hParent:DWORD, ID:DWORD
      INVOKE  CreateWindowEx, WS_EX_CLIENTEDGE, ADDR RichClass, 0,
      WS_VISIBLE or WS_CHILDWINDOW or ES_SUNKEN or \
      ES_MULTILINE or WS_VSCROLL or WS_HSCROLL or \
      ES_AUTOHSCROLL or ES_AUTOVSCROLL or ES_NOHIDESEL,
      x, y, wd, ht, hParent, ID, hInstance, NULL
      RET
   RichEdit   Endp
   ;


***********************************


Even if file is modified, the return(EAX) value has not TRUE(1).
it has FALSE(0) or any Hexa value, in my check.

      INVOKE  SendMessage, hRichEdit, EM_GETMODIFY, 0, 0
      .IF EAX == TRUE


I don't know it's reason.




MichaelW

The attachment is a small test app that you can use to verify that the EM_GETMODIFY and EM_SETMODIFY messages work as they are documented to work.

[attachment deleted by admin]
eschew obfuscation

Tedd

When checking for true/false values:
0 => false
else => true

It doesn't just have to be 1 for true, it's any value that isn't zero.
No snowflake in an avalanche feels responsible.

vega

#5
I am sorry for my too late response.

MichaelW,
thanks for your good example.
I did check out your example that executes well.

and Tedd,
thanks for your good advice.
I understood it.

But, I don't know the cause of my problem, yet.
Please, check attached my Test.Program and teach me why it doesn't executes.




[attachment deleted by admin]

Tedd

..it does work..

run.. close = silent close.
run.. type letters.. close = messagebox("save?")
run.. new = 'new'
run.. type letters.. close = messagebox("save?")


What isn't working?
No snowflake in an avalanche feels responsible.

vega

Yes, it is ok.
But the problem occurs after any 'file open'.  :'(

run.. file open.. close = messagebox("save?")                         ....abnormal!
run.. file open.. type letters.. close = messagebox("save?")      ....normal


hutch--

vega,

You use the GETMODIFY message to find out if the text in the rich edit control has been modified or not, you use the SETMODIFY message to set it to either modified or NOT modified. Whats the big deal ?
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

vega

I see now,
it seems the problem stays in the  'OPEN_FILE_PROCESS' of my program.

run.. file open.. (None type letters).. close = messagebox("save?")          ....abnormal

vega

I solved this problem by adding one line in the 'OPEN_FILE_PROCESS' Routine as follows..
It is no needs on 'Edit control'.
Is this right method?
Is there any other way for this problem?


            OPEN_FILE_PROCESS:
               INVOKE SendMessage, hRichEdit, EM_GETMODIFY, 0, 0
               .IF EAX
                  ;if the Contents in an RichEdit.control has been modified,
                  CALL  WORKING_FILE_SAVE_ROUTINE
                  .IF EAX == IDCANCEL
                     JMP  DEFAULT_MESSAGE_PROCESS
                  .ENDIF   
               .ENDIF
               
               ;Write_OpenFileName_Parameters_into_Field_of  FileNameStruct
               MOV  EAX, hWin
               MOV  FileNameStruct.hWndOwner, EAX

               MOV  EAX, hInstance
               MOV  FileNameStruct.hInstance, EAX
           
               MOV  FileNameStruct.lStructSize, SizeOf OPENFILENAME
               MOV  FileNameStruct.lpstrFilter, OFFSET OpenFileFilter
               MOV  FileNameStruct.lpstrFile, OFFSET FileNameBuffer
               MOV  FileNameStruct.nMaxFile, SizeOf FileNameBuffer
             
               MOV  FileNameStruct.lpstrTitle, OFFSET OpenProgressTitle
               MOV  FileNameStruct.Flags,
                       OFN_EXPLORER or OFN_FILEMUSTEXIST or OFN_LONGNAMES or OFN_HIDEREADONLY   
               
               ;Display_File_Open_Dialog_Box_for FileNameStruct
               INVOKE GetOpenFileName, ADDR FileNameStruct
               .IF EAX == FALSE
                  JMP  DEFAULT_MESSAGE_PROCESS
               .ENDIF   
   
               ;Display_Window_Title_with_String_of FileNameBuffer
               INVOKE SetWindowText,  hWin, ADDR FileNameBuffer
               ;Open_Exist_File
               INVOKE CreateFile,  ADDR FileNameBuffer, GENERIC_READ, NULL, NULL,
                                   OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL
               MOV  hFile, EAX
               
               INVOKE GetFileSize, hFile, NULL
               MOV  FileSize, EAX
               ;Make_Global_Buffer_Memory
               INVOKE  GlobalAlloc, GMEM_FIXED, FileSize
               MOV  hFileBuffer, EAX
               
               ;Read_File_to  hFileBuffer
               INVOKE ReadFile,  hFile, hFileBuffer, FileSize, ADDR ReadedBytes, NULL
               ;Display_FileBuffer_Text_on_RichEditBox
               INVOKE  SetWindowText, hRichEdit, hFileBuffer

               ;Clear_Modification_Flag
               INVOKE  SendMessage, hRichEdit, EM_SETMODIFY, FALSE, 0
               
               INVOKE  CloseHandle, hFile
               ;Release_Global_FileBuffer_Memory
               INVOKE  GlobalFree, hFileBuffer
            JMP  DEFAULT_MESSAGE_PROCESS
   

Tedd

Yeah, that's it - you have to set modify back to false after you load a file because loading a file is inserting text, which is a modification :U
No snowflake in an avalanche feels responsible.

vega

Thank you, Tedd.
I understood principle points by your good advices.
but, I have one question, yet.
Why does not occur this problem in an Edit.Control?

Tedd

Short answer: I don't know :lol
I don't know if it does or not (without testing,) but I don't think it should/would. It depends exactly what your code did, etc.
No snowflake in an avalanche feels responsible.

vega

Lots of thanks..!
with most regards to MASM.FORUM  :bg