Having a moment :idea:
With a visual project.. what type of control is the GROUP box ?
I'm trying to make it invisible when not used...
I've tried ShowWindow, but that doesn't seem to work...
Would it be a SetWindowLong property setting ?
Cannot seem to find any info on this... maybe I'm looking in the wrong place
:icon_eek:
i don't think it's really a control - it's a style assigned to a group of controls
BS_GROUPBOX, WS_GROUP, WS_TABSTOP
my mistake :P
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511459.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa511459.aspx)
it appears to be a .NET form
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318098%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318098%28v=vs.85%29.aspx)
but, essentially a button class
QuoteThe window class name for a group box is "BUTTON".
so, i guess you make a button with BS_GROUPBOX style
Thanks.. 'I can see clearly now.. the rain has gone' :icon_mrgreen:
It looks like I must swop the WS_VISIBLE style in and out.. I'll try this.
if all else fails set the size and or position
if the width or height is 0, it's not visible :P
It draws a frame around other controls. If I remember well, it serves also to delimit the scope of autoradiobuttons. For example, you may have two sets of BS_AUTORADIOBUTTON controls - there must be a way to decide which two buttons are active.
It must have something to do the the Group Style... I've checked my handles, and message parameters... all looks OK
Yet it still fails on ShowWindow and SetWindowLong... ??
:icon_exclaim:
Not to worry.. I'm onto it....
My handles are now being zero'ed where I've yet to find out :-)
xor ecx,ecx
INVOKE SetWindowPos,hControl,ecx,ecx,ecx,ecx,ecx,SWP_HIDEWINDOW or SWP_NOMOVE or SWP_NOSIZE or SWP_NOZORDER
Attached an example with two independently working groups of autoradiobuttons.
*dbg*.exe shows all window messages, and WM_PARENTNOTIFY in particular.
Hi K_F,
First of all you have to get the Group's handle with the GetWindowItem method. For example, if the Window name is Window1 and the Group name is Group1, the code would be the following (hWnd is the handle of the window where the Group is in):
Invoke GetWindowItem, hWnd, IDC_WINDOW1_GROUP1
After that call , the Group's handle is in Eax register. Then you can hide the group by using the ShowWindow API call:
Invoke ShowWindow, Eax, SW_HIDE
Or by using the SetVisible method:
Invoke SetVisible, Eax, FALSE
I attach a simple example for you to see how to Show / Hide a Group control.
Regards,
Ramon
Ramon,
The interesting question here seems how to get two groups of controls (here: BS_AUTORADIOBUTTON) working independently, as shown in this screenshot of the app posted above.
There are apparently two methods of grouping radio buttons into functional sets. One is to make each button in the set a child of a group box. The other is to apply the WS_GROUP style to the first button in the set, so the set will extend up to, but not including, the next button in the tab order that has the WS_GROUP style.
;==============================================================================
include \masm32\include\masm32rt.inc
;==============================================================================
.data
state dd 0
.code
;==============================================================================
DlgProc proc hwndDlg:dword, uMsg:dword, wParam:dword, lParam:dword
SWITCH uMsg
CASE WM_COMMAND
SWITCH wParam
CASE IDCANCEL
invoke EndDialog, hwndDlg, 0
ENDSW
CASE WM_CLOSE
invoke EndDialog, hwndDlg, 0
ENDSW
xor eax, eax
ret
DlgProc endp
;==============================================================================
start:
;==============================================================================
Dialog "Test", "MS Sans Serif",10, \
WS_OVERLAPPED or WS_SYSMENU or DS_CENTER, \
4,0,0,200,150,1024
DlgRadio "AutoRadioButton1",WS_TABSTOP or WS_GROUP,65,30,70,10,100
DlgRadio "AutoRadioButton2",WS_TABSTOP,65,50,70,10,200
DlgRadio "AutoRadioButton3",WS_TABSTOP or WS_GROUP,65,80,70,10,300
DlgRadio "AutoRadioButton4",WS_TABSTOP,65,100,70,10,400
invoke GetModuleHandle, NULL
CallModalDialog eax,0,DlgProc,NULL
exit
;==============================================================================
end start
Quote from: MichaelW on December 21, 2013, 10:32:53 AM
There are apparently two methods of grouping radio buttons into functional sets. One is to make each button in the set a child of a group box.
See my example.
QuoteThe other is to apply the WS_GROUP style to the first button in the set, so the set will extend up to, but not including, the next button in the tab order that has the WS_GROUP style.
Good to know :t
It doesn't paint the group rectangle, though, but apparently that is exactly what the OP wanted.
WS_TABSTOP can also be used with WS_GROUP'ed controls to modify tab behaviour
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).
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
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
:)
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
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
:)
Hi K_F,
Sorry, but I really don't know what you mean. May I see some example(s) please?
Thanks!
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
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 ?
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
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
did you try Beep ?
Not yet.. I'll try tomorrow
thanks
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
(http://img706.imageshack.us/img706/5476/e0l8.png)
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
(http://img706.imageshack.us/img706/5476/e0l8.png)
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.
:)
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
Danke, Mein Herr !
How's my German... the German speakers ? :t
Those colours and fonts remind of the old Hercules card.. Ok it was usually green.. but with an orange monitor is look very much the same
:biggrin:
View menu - you can select background and foreground colors - and it will remember them for you :P
Quote from: dedndave on December 24, 2013, 07:47:48 AM
..- and it will remember them for you :P
You know, it's quiet amazing how many bits of software lack this nice little feature..
:t
i originally had that stuff in the registry, but switched to a small config (bin) file
it also remembers text size and window size, but not window position
i thought it best to let windows locate the window
it only remembers for one instance though - i may update that so the 2 instances can look different
Hi K_F,
Quote from: K_F on December 24, 2013, 07:40:05 AM
Danke, Mein Herr !
How's my German... the German speakers ? :t
your German is flawless. :t Did you have a little bit help by Google translator?
Gunther
Hi dedndave,
The ECM_AFTERCREATE message is Easy Code defined (just for visual projects). It's sent to the window being created after it and its children are completely created and before the window is shown.
Regards!
Hi K_F,
Please give me some time to study your code and I'll come back to you.
Ramon
Quote from: Gunther on December 24, 2013, 08:02:51 AM
your German is flawless. :t Did you have a little bit help by Google translator?
Nope.. it's just a little bit that I've 'picked up' over the years..
I've (and the wife :icon_eek:) always watched a lot of doccies over the years on WW2, especially wrt to the German and Russian points of view... the sides that you don't hear much about.
It was really funny at my in-laws one day.. my wife's grandfather was Italian-British (war vet) and our eldest kid, who was about 4 or 5 years old and had been watching most of the german doccies with us.. said to my father in law... (this came out of the blue!!)
"Grandpa.. do you know I can speak German !! "
"Really!! speak to me then "
"Sieg Heil !!"
I fell over laughing, my in-laws eyes bulged... and then they looked accusingly at me... I shrugged my shoulders.
He'd innocently picked this all up from the video's, and had no idea about what he was saying.
Naturally we educated him more as the years moved on.. but it was as funny moment!!
:biggrin:
Hi K_F,
Quote from: K_F on December 24, 2013, 05:06:34 PM
I fell over laughing, my in-laws eyes bulged... and then they looked accusingly at me... I shrugged my shoulders.
He'd innocently picked this all up from the video's, and had no idea about what he was saying.
Naturally we educated him more as the years moved on.. but it was as funny moment!!
:biggrin:
oh yes, a lot of fun.
Gunther