Ken Shmidheiser wrote:
>> Ken Shmidheiser wrote:
> 
> Thank you so much for taking a huge chunk of your time to help me and 
> others
> here understand DBFD! I called up several listings in excess of 37,000 
> words
> and it worked flawlessly. This could be the solution to displaying some 
> of the
> large files we've been creating lately, i.e., a word list preview browser
> in Word Indexer, for instance.
> 
> I'm working on several projects that could use this capability.
> 

That's right, I have spent some time to answer, maybe too much 
especially at the moment, but it was due more to my difficulties with 
the English language than the coding in itself. I agree that there are 
many instances where we can benefit from that control.

> Now a few questions:
> 
> 1.) In an attempt to implement copying a selected word from
> the menu to the Clipboard, I wrote the following function:
> 
> local fn DataBrowserCopy
> 
> long if fn EnableDataBrowserEditCommand ( gBrowser, 
> _kDataBrowserEditMsgCopy )
> long if fn ExecuteDataBrowserEditCommand ( gBrowser, 
> _kDataBrowserEditMsgCopy )
> xelse
> beep
> end if
> end if
> 
> end fn

<snip>

> 
> Alas, it fails. Any suggestions about where I'm going wrong? The 
> constants make
> it appear easy to set up the Edit Menu, but I'm missing something.
> 

I admit I have not studied, let alone experimented, those commands, but 
my take is that they are useful when you start an edit session in a 
cell, since your program cannot know what is the selection that the 
end-user has made in the cell's content. Other than that, your prog can 
easily retrieve which cell(s) is(are) selected therefore it can handle a 
cut/copy operation on its own (it knows what to put on the clipboard, 
while the DataBrowser doesn't).

> 2.) The scroll bar fails to extend to the bottom of the browser, leaving 
> an unsightly
> gap that's reserved for the horizontal scroll bar. Is there anyway to 
> overcome
> this behavior? I tried playing with the widths set in the headers at 13, 
> but was only
> able to widen the browser window.

I saw that, but didn't spend time to fix the bug. It is indeed a bug in 
the DBFD library that is repaired by now (I hope). It was a bad idea to 
work exclusively with a DataBrowser in full window mode when developing 
the library, I have probably missed other bugs.
There are specific values called scrollbarinset that set the sizes of 
the vertical and horizontal scrollbars. Normally, you can modify those 
values dynamically using specific functions, like the DBFD function 
BrowserSetVScrollbarInset, but I have probably screwed up something here 
too, because it doesn't seem to work as I want.

To fix the DBFD library:

Locate in the BrowserCreate function the following lines:

Long if hBar or vBar
err = Fn GetDataBrowserScrollBarInset( browser, r )
if hBar then r.right  = 13
if vBar then r.bottom = 13
err = Fn SetDataBrowserScrollBarInset( browser, r )
end if

exchange right with bottom to get this:

Long if hBar or vBar
err = Fn GetDataBrowserScrollBarInset( browser, r )
if hBar then r.right  = 13
if vBar then r.bottom = 13
err = Fn SetDataBrowserScrollBarInset( browser, r )
end if

> 
> 3.) The minimum browser width was set at 167 in your example. Since the 
> DataBrowser
> uses a larger system font that what I used in the EF, I had to go back 
> and widen
> the browser so long words weren't truncated. However, at 167 the browse 
> exhibited
> weird behavior so I reset it to 200 and it works fine. Any guidelines on 
> how this should be
> set, for instance, how to you reach 167.

I set 167 pixels with trials and errors, but it should be calculated I 
guess. I don't know of any guidelines for that.
The important thing is to set at least a minimum width (this value is 
set to zero with the BlockZero Toolbox procedure) in order to see 
something on the screen.
Note that the width of the columns can be handled dynamically by the 
DataBrowser without you having to write a single line of code, idem for 
the column position (the end-user can drag a column at a different 
place). If you want a fixed-size column, you can set list.maxWidth to 
the same value than list.minWidth.
If you want to set the font style of the text that appears in the list, 
do this in the general settings, before creating the control. In Jaguar, 
I had a hard time to change the display afterwards, and I ended up 
removing that feature from QuiXample only when it is running in OS X. It 
seems that there's a bug in the Apple DataBrowser API (it works in Mac 
OS 9, I have not checked with Panther though). You can do this for example:

list.cellStyle[_cellTextFont] = _times
list.cellStyle[_cellTextSize] = 12
list.cellStyle[_cellTextFace] = 0
list.cellStyle[_cellTextMode] = _srcOr

I know I have not answered precisely your question, so I'm trying to 
give you some hints for a possible workaround.

> 
> 4.) How difficult is it to detect a click on a browser item and retrieve 
> the selected data?
> I know you did this in the DBFD tutorial demo.

The answer is quite simple. The DataBrowser can give you some 
information about what is going on with the end-user interaction. As 
usual, the DataBrowser communicates with your program through a callback 
procedure. The proc is called ItemNotification. That is really easy to 
implement. In the general settings you need to add the callback local fn 
you intend to use:

list.procs[_ItemNotification] = @Fn MyItemNotification

Same remark as for the GetSetItemData callback proc/function, you can 
name it like you wish but the argument list should follow the expected 
format. I have included in the DBFD package a file called "DataBrowser 
Callback Templates" where you can find how you should declare each one 
of the 17 callback procs you can install in a DataBrowser control. A 
copy/paste operation will do the trick. Here is a short piece that will 
show an alert box when the user double-click on an item in the list:

clear local fn MyItemNotification( browser as ControlRef,              ¬
                                  itemID as DataBrowserItemID,          ¬
                                 message as DataBrowserItemNotification )
  select message
   case _kDataBrowserItemDoubleClicked
     ParamText("Double-clicked Item:",str&(gWordListH,itemID),"","")
     if fn Alert(1,_nil) then beep
  end select

end fn
> 
> Now that you've whet my appetite, I'll be spending some more time DBFD. 
> If we can
> get it to interact with FB^3 without a lot of pain, it will be a 
> wonderful addition.
> 
I would say that currently, it is not that simple, especially for 
beginners, that's why I wrote DBFD. Well, it was for me in the first 
place, but I know it can help others. The important work for the 
experimented programmers is the Tlbx ControlDefinitions.Incl header 
file. It was a huge job too. The cool thing about the library is that a 
lot of code is already written for us, this includes, thanks to R.P. as 
usual, a snippet of code that installs a carbon event handler just to 
activate the window when the end-user clicks in the DataBrowser area. 
The DataBrowser is a bit special, it is to note that it works better 
with Carbon events, and I don't think it can be treated by the runtime 
in the same manner as the other controls. However, the important thing 
is to grasp the concepts which are not actually as difficult as I 
thought, after that the rest becomes a lot easier, and even more so with 
DBFD.

> Thanks again for you patience and work. Looking over the headers I can 
> only imagine
> the hours you have spend on this. I hope Staz sees fit to include in the 
> R8 headers.
> That way we won't have to go looking.
> 

The DBFD package will probably be included in the R8 CD, maybe in the 
Donations folder. I hope that the Tlbx ControlDefinitions.Incl file will 
be added to the headers at some time in the future.

Alain