Author |
Topic: GUILIB (Read 622 times) |
|
Matt
Developer
member is offline


Gender: 
Posts: 210
|
 |
Re: GUILIB
« Reply #41 on: Jan 4th, 2014, 05:20am » |
|
ListView Section:
This is supposed to be part of the GUILIB, but I'm not sure if you want to make it a different thread. (If you do, I can copy and paste it to a new thread, therefore not losing the first message.)
I've created several routines that create, and manipulate a ListView in 'Report Style'. Rather than list all I've done (especially if the 'create' is no good) I'll deal with one section at a time.
Richard, is this something like you're after:
Code: REM TEST AREA
INSTALL @lib$+"WINLIB5A"
ON CLOSE PROC_closewindow(H%) : QUIT
DIM hdr$(5), wid%(5), jst%(5)
FOR I% = 0 TO 5
hdr$(I%) = "Header " + STR$(I%)
wid%(I%) = 120
jst%(I%) = I% MOD 3
NEXT
H% = FN_lv_setup(@hwnd%, 0, 40, 800, 300, hdr$(), wid%(), jst%(), -1, &2000001)
END
REM /TEST AREA
REM Create a standard List View. Returns the handle of the List View
REM Perameters: h% = parent window handle%,
REM x%, y% = coordinates of the top left corner;
REM cx%, cy% = width & height of the LV;
REM header$() = header text array;
REM width%() = column width array;
REM justify%() = column justification array;
REM lastcol% = last column set (zero-based)
REM style% = style of the LV
REM LOCAL vars: LVCOLUMN{} = listview column structure
REM D% = LV handle
REM C% = column count
REM H$ = header string
DEF FN_lv_setup(H%, X%, Y%, W%, V%, H$(), W%(), J%(), L%, S%)
LOCAL LVCOLUMN{}, D%, C%, H$
LVCF_FMT = &1
LVCF_WIDTH = &2
LVCF_TEXT = &4
LVCF_SUBITEM = &8
LVM_INSERTCOLUMN = &101B
DIM LVCOLUMN{ mask%, fmt%, cx%, pszText%, cchTextMax%, iSubItem% }
LVCOLUMN.mask% = LVCF_FMT OR LVCF_SUBITEM OR LVCF_TEXT OR LVCF_WIDTH
IF L% > DIM(H$(), 1) OR L% < 0 THEN L% = DIM(H$(), 1)
SYS "InitCommonControls"
D% = FN_createwindow(H%, "SysListView32", "", X%, Y%, W%, V%, 0, S%, 0)
FOR C% = 0 TO L%
H$ = H$(C%) + CHR$(0)
LVCOLUMN.fmt% = J%(C%) MOD 3
LVCOLUMN.cx% = W%(C%)
LVCOLUMN.pszText% = !^H$
LVCOLUMN.cchTextMax% = LEN(H$)
LVCOLUMN.iSubItem% = C%
SYS "SendMessage", D%, LVM_INSERTCOLUMN, C%, LVCOLUMN{}
NEXT
= D%
There is no structure created, unlike what we are trying to do with the other windows. Is creating a structure required on all the windows for the GUILIB?
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GUILIB
« Reply #42 on: Jan 4th, 2014, 10:00am » |
|
on Jan 4th, 2014, 05:20am, Matt wrote:| Richard, is this something like you're after |
|
It looks to have the right kind of feature-set. Have you thought about the issue of converting the column-width values from pixels to dialogue-box-units, which presumably will be necessary when the List View is hosted in a dialogue box?
Quote:| Is creating a structure required on all the windows for the GUILIB? |
|
I suppose it depends on how you intend to deal with creating the List View in a dialogue box rather than in a regular window (see for example the BB4W 'Compile' dialogue, in which the 'Embedded files' list is a Report Style List View).
The assumption I've always made is that it will be necessary to store the information relevant to each control in some kind of temporary structure, and then when the parent dialogue box or window is eventually opened that stored information will be used to create the controls.
If you don't use a structure of some kind it's not clear to me how you can (easily) achieve a common syntax for creating a control in a dialogue and in a regular window, which is one of the features that GUILIB is expected to provide.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline


Gender: 
Posts: 210
|
 |
Re: GUILIB
« Reply #43 on: Jan 10th, 2014, 07:35am » |
|
on Jan 4th, 2014, 10:00am, Richard Russell wrote:| Have you thought about the issue of converting the column-width values from pixels to dialogue-box-units, which presumably will be necessary when the List View is hosted in a dialogue box? |
|
This is getting embarrassing, not to mention incredibly frustrating. I've never put a LV in a dialog box and, try as I might, I can't figure out a way to do it!! I know it's just another window, but I'm stuck. I've trawled through the Windows control library and through the LIBs, but I'm just not seeing what I need to.
HELP!
Matt
(Incidentally, are you having problems viewing your replies with the Preview button here?)
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline


Gender: 
Posts: 321
|
 |
Re: GUILIB
« Reply #44 on: Jan 15th, 2014, 3:40pm » |
|
Hi Folks,
Toys back in the pram though they weren't thrown out for quite the childish reason you attributed to me.
I've posted on Wiggio another go, much closer to what you describe in the wiki, which might or might not be what you are looking for. All structures are now hidden under the bonnet, and don't need (or get) names.
A number of issues come to my mind:
1) I obviously haven't got the space calculation quite right, since I've had to add a fiddle factor...
2) I end up with a pointer to the structure used to define the dialogue box (wh%), and also a handle for the dialogue box (dlg%). In line with Richard's suggestion before Christmas I've moved towards using dlg% and id% for subsequent manipulations, but then I can't see how to get the routines to go back and change the contents of the structures. Effectively, the structures just get thrown away (but as far as I can see the memory not released) once the dialogue template is actually created. If I used wh% instead of dlg% I could modify the structure(s - including the control structures if needed, though I'd need to chase through the linked list), but it would be a bit slower and clunkier (though that would be hidden under the bonnet).
3) It seems to me that I need 3 instructions to create the DB now - one to initialise the structure, one to create the DB template, and then one to show it. I could combine the latter two, but I'd still want to be able to show/hide the DB again, so I'd still need the "showdialog".
Best wishes,
D
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline


Gender: 
Posts: 25
|
 |
Re: GUILIB
« Reply #45 on: Jan 31st, 2014, 10:15pm » |
|
Hi Folks,
Over the past couple of days, I have made a stab at section 1 of Richard's GUILIB specification, specifically:
1.1, 1.2, 1.3, 1.4, 1.7
http://wiggio.com/yui/folder/stream_file.php?doc_key=qzoGwHPMw5YPmQHvlem1YJwv2VPYvWN4fAwoh5i5FIE=
The start of the file contains some code to demonstrate its use. I have made no attempt to include code to handle events, so if you run it, its best not to click on anything until its done. I think it succeeds in setting 'a' foundation for a simple unified interface for all window types and controls, but I've achieved this using brute force and ignorance. You'll see what I mean.
Theoretically, I could continue in this fashion and meet most of the specifications for GUILIB, but I think it would turn into the 'John Logie Baird' rather than the 'Marconi-EMI' of GUILIBs.
http://www.bbc.co.uk/programmes/p019d7fl
Thanks
Andy
|
|
Logged
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GUILIB
« Reply #46 on: Feb 1st, 2014, 09:56am » |
|
on Jan 31st, 2014, 10:15pm, Andy Parkes wrote:| Over the past couple of days, I have made a stab at section 1 of Richard's GUILIB specification |
|
Not content with three people (seemingly) independently working on GUILIB, we now appear to have a fourth!
Whilst the last thing I want to do is to curb enthusiasm, which is sorely lacking (not least on my behalf!), this is no way to run a software project! The idea was that GUILIB would be a collaborative effort; quite how the work might be farmed out I don't know - presumably there would be somebody (not me!) in overall control.
A prerequisite for a 'team' development is for the specification to be sufficiently detailed and complete that everybody knows what is being aimed for, and I don't think the existing spec achieves that.
So can I ask that Matt, Svein, David and yourself get your heads together, decide who is going to be in charge, update the spec (I would want to take a role in that) and then work out how to proceed from there?
If you, collectively, don't feel that a collaboration is possible I'm not sure how we should proceed. I don't want to be presented with several independent offerings from which I am expected to cobble together some kind of Frankenstein's monster of a library. 
Richard.
|
|
Logged
|
|
|
|
|