News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Group control

Started by K_F, December 19, 2013, 07:56:28 PM

Previous topic - Next topic

rsala

Hi jj2007,

If did not misunderstood your question, you just need two Group controls. Radio buttons inside each Group will work independently (that works in Easy Code visual projects).
EC coder

K_F

I got it,  Yeeeeeeehaaahhh!!  :eusa_boohoo:
Thought I was going nuts

Ramon.. I think there might be a problem with scope of variables with personal INC file public data.

I get window handles from an added module (.asm file), and save the handles to variables (structure) declared in my own INC file
My module code can see my INC file variables, but the window module procedures cannot see my INC file variables, although reads all variables as 0h.
When I moved my procs that hide/display the groups to my asm module.. all worked

There are no assembly errors and all assembles/compiles OK, so I thought my INC files variables were global.. apparently not, unless I've 'boo-boo'ed' some where!!
I added my Modules and INC files according to the Easycode help file method, for global visualisation.... this seemed to make no difference

:t
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

K_F

Had to go shopping with the wiff.. but thinking about this..

It seems that the variables in my own INC are being mirrored (a duplicate copy) and then my ASM module accesses one lot, and the window module accesses the mirrored variables.. which are never set, as I'm setting all my variables in my ASM modules.

Depending from where you access the variables, determines which 'side of the mirror' it is.
The funny thing is that the assembler/linker doesn't pick this up
:)
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

rsala

Hi K_F,

Variables in an INC file (included with the  "Add files..." option) should be global. I will have a look at the source code to try to find bugs.

Regards,

Ramon
EC coder

K_F

It does look like they're global (the assembler/compiler doesn't report any errors), but the windows module code seems to be accessing different variables with the same name, as my added ASM module code.
All my variables are in my own INC file..

Hope this helps
:)
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

rsala

Hi K_F,

Sorry, but I really don't know what you mean. May I see some example(s) please?

Thanks!
EC coder

K_F

#21
I'll try make it logical as I can...  :biggrin:

I create an INC file (Blue) and place all my variables here.

I create an ASM module (Yellow) and from here I :-
- Get the Group handle and all it's internal control handles, and save these handles to the INC file.

In the Window module (Red) I :-
- Try to use the handles set in the INC file (Blue), to turn the groups on/off
- This doesn't work as I noticed that handles being used in this proc are Zero (0h).
- but I've already set the handle values in my INC file

So I move the procedure from the Window module(Red) to the Asm Module(Yellow) and :-
- All works as it should.... the handles used are correct.

Conclusion:
- The ASM module is using the INC file variables
- The Window module is using some other variables of the same name.. maybe a duplicate copy of my INC file
   as all the values retrieved here are Zero (0h)
- I assume variables of the same name, and duplication, as the Assembler/Linker does not pick up a problem.
- The only time I write to the handle structures is during Initialisation and with the GetWindowItem procs
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

dedndave

sounds to me like you are trying to use the handles before TYPE_GetHandles is called
or perhaps you are calling it before the controls are created (i think you ruled that out)

the uninitialized values are zero - this tells me they probably aren't on the stack (duplication?)
the assembler and linker will not allow duplicate names, unless they have local visibility
if the INCLUDE statement precedes the rest of the code, it should be globally visible

conclusion - the order of execution is the problem
we can't see if that's the case with the limited info you've given us   :(

what we cannot see.....
where is the INC file included (at the beginning of the program ?)
where is the call to TYPE_GetHandles - at what point do they get initialized
is it a dialog box or WndProc ?
WM_INITDIALOG ?
WM_CREATE ?

dedndave

if you aren't running under vista, you can use Beep as a quick troubleshooter

where the controls are created, insert
invoke Beep,200,40

where the control handles are initialized, insert
invoke Beep,400,40

where you are trying to access the handles, insert
invoke Beep,800,40

you will hear what's happening in less than 1 second   :P
if the succession of beeps is too fast, follow each of the above lines with a Sleep,40 or something

K_F

I'm running on Win7 Pro.

Quotewhat we cannot see.....
where is the INC file included (at the beginning of the program ?)
Using an Easycode visual project... placed in the include section in the projects window - this should be global I'm not sure how Easycode does it
Quote
where is the call to TYPE_GetHandles - at what point do they get initialized
is it a dialog box or WndProc ?
The  TYPE_GetHandles is in the ASM module, but this is called from the main WndProc on the uMsg == ECM_AFTERCREATE message.
The hWnd parameter is passed to TYPE_GetHandles and used to.
The Initialise procs do not touch the handle structures..

Quote;------------------------------------------------------------------------------
;winLooterProcedure:
;------------------------------------------------------------------------------
winLooterProcedure Proc hWnd:HWND, uMsg:ULONG, wParam:WPARAM, lParam:LPARAM


   .If uMsg == WM_CREATE

   .elseif uMsg == ECM_AFTERCREATE
      invoke   GetHandles_All, hWnd
      invoke   Initialise_All, hWnd


   .elseIf uMsg == WM_COMMAND

   .elseif uMsg == WM_NOTIFY

ASSUME eax:PTR NMHDR
      mov      eax, lParam
      mov      eax, [eax].hwndFrom
ASSUME   eax:NOTHING
      .if   eax == MyTabHandle.h_tabLooter
         invoke winLootertabLooter, hWnd, uMsg, wParam, lParam
      .endif

   .elseIf uMsg == WM_CLOSE
      Invoke IsModal, hWnd
      .If Eax
         Invoke EndModal, hWnd, IDCANCEL
         Mov Eax, TRUE ;Return TRUE
         Ret
      .EndIf
   .EndIf

   Xor Eax, Eax   ;Return FALSE
   Ret
winLooterProcedure EndP
;-----------------------------------------------------------------------------
;GetHandles_All:
;-----------------------------------------------------------------------------
GetHandles_All    Proc   hWnd:DWord

   Invoke GetWindowItem, hWnd, IDC_WINLOOTER_TABLOOTER

   .if eax != 0
      mov      MyTabHandle.h_tabLooter, eax

      invoke   TYPE_GetHandles, hWnd
      invoke   TOTALS_GetHandles, hWnd
   .endif
   ret

GetHandles_All      EndP
In the Asm module..
Quote;-----------------------------------------------------------------------------
;
;-----------------------------------------------------------------------------
TYPE_GetHandles    Proc   hWnd:DWord

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_GRPTYPE
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_GrpType, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_CMBTYPE_DRIVE
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_cmbTYPE_Drive, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_LSTTYPE_FOLDERS
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_lstTYPE_Folders, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_LSTTYPE_FILES
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_lstTYPE_Files, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_EDTTYPE_FILENAME
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_edtTYPE_FileName, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_EDTTYPE_CELL
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_edtTYPE_Cell, eax

   Invoke    GetWindowItem, hWnd, IDC_WINLOOTER_LVTYPE_RESULTS
   Cmp      Eax, NULL
   jne      @F
   jmp      TGF_Fail
@@:
   mov      MyTypeH.h_lvTYPE_Results, eax
   Return   TRUE

TGF_Fail:
   invoke   MessageBox, hWnd, TextAddr("Failed"), TextAddr("TYPE_GetHandles"), MB_OK   
   Return   FALSE
TYPE_GetHandles      EndP
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

dedndave


K_F

Not yet.. I'll try tomorrow
thanks
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

dedndave

ECM_AFTERCREATE is new to me - lol
i don't use EasyCode   :P

but, it would seem your code verifies the handles are non-zero by way of the message box
so - you just need to verify that the handles are initialized before you try to access them

i am not sure how Ramon manages the ECM_AFTERCREATE message
but, i see some potential issues with it

below is a picture that shows the messages from both the main window and the (child) text window at startup
you can see what order things are executed
WM_SIZE is a good example of where things might go wrong if a global handle is not initialized during a child's WM_CREATE


K_F

Quote from: dedndave on December 24, 2013, 03:01:17 AM
WM_SIZE is a good example of where things might go wrong if a global handle is not initialized during a child's WM_CREATE

Interesting.. I'll look at that...
What was this message monitor program again ? Vaguely remember it being here somewhere - I'd like to use it.
:)
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

dedndave

some time ago, i wrote a program that runs in 2 modes - a host mode, and a client mode
the 2 windows communicate with each other using WM_COPYDATA

i made a specialized variation of it to monitor WndProc messages
the messages received in the WndProc and TxtProc windows of the host app are sent to the client app to be displayed
the messages are placed into a circular buffer before being sent/displayed

i have never fully documented the project - nor do i want to start on that today - lol
but, you are welcome to play with it

you can filter out messages so they are not displayed
as an example, WM_NULL messages are not displayed - edit the WmFilter.inc file to add others
WM_COPYDATA messags are automatically filtered out   :P