Logo107.22.109.65 
  Home  News  Recent  Forums  Search  Contact
  Menu
 Username

 Password


   Register here

 Main menu
   View images
   BBCode test
 
 Content
   Statement of intent
   Terms Of Service
   IRC Channel
   List Content

 In cooperation with
  OS4Depot.net
  OpenAmiga.org
  OS4Welt

 Links
  AmigaOS4
  IntuitionBase
  UtilityBase
  Amiga Flame
  Amiga Spirit
  AmiKit
  Aminet
  AmiBay
  AmigaBounty
  AmigaWorld
  Exec
  Amiga.cz
  View comments
Title  
  Forums
    Development
      AmigaOS 4  
Navigate: 1-20 21-40 41-60 61-73 
rigoRe: Reaction Improvements20110207 23:56  #1951
@chris

It is. Have a look at layout_gc.doc

Simon
chrisRe: Reaction Improvements20110208 00:32  #1953
@rigo

I only see it in relation to LAYOUT_DeferLayout, your copy will be vastly more up-to-date than mine though, so I guess it has been added since the last public SDK release.
centaurzRe: Reaction Improvements20110212 17:10  #2074
@Rigo

I've found a bug in V53 listbrowser.gadget, where should I report it ?
rigoRe: Reaction Improvements20110212 17:54  #2075
@centaurz

You could try here first...

Simon
centaurzRe: Reaction Improvements20110212 18:10  #2076
@rigo

OK. It looks like the tab editing feature is broken, the content of an editable cell is no longer updated when you press <TAB> (it just gets back to its initial value). To reproduce the problem, you can modify LB_Example.c in the SDK by passing the relevant tag-list for LISTBROWSER_EditTags attribute.
rigoRe: Reaction Improvements20110212 18:56  #2078
@centaurz

Could you mail me the modified example code so I can try it here...

Simon
centaurzRe: Reaction Improvements20110212 19:45  #2081
@rigo

I couldn't find your e-mail, but actually you just have to declare this in main:


struct TagItem edittags[] = {
{ GA_TabCycle, TRUE },
{ TAG_DONE, 0L}
};


and add this tag to ListBrowser:


LISTBROWSER_EditTags, edittags,

rigoRe: Reaction Improvements20110212 20:28  #2083
@centaurz

OK, I'll give this a try and see...

Simon
rigoRe: Reaction Improvements20110213 12:04  #2104
@centaurz

OK, I've tried this, but in all honesty I'm not really sure what you are expecting here.

GA_TabCycle is designed to add a gadget into a TAB/Shift-TAB group, which naturally implies more than one. When the listbrowser node is being edited, there is only one string gadget, not one for each column. Once the node has been edited the string gadget is disposed of, so GA_TabCycle cannot work. In conjunction with this, TAB'ing out of the string gadget is regarded as an escape operation, only <return> or <enter> can confirm the changes (unless GA_RelVerifySpecial is supplied, which listbrowser doesn't).

I assume you are trying to TAB across a multi-column node that is being edited, but this cannot work with GA_TabCycle, as there is only one string gadgets in play during editing.

You do, however, get notified once a column has been edited, so you could activate the next column in the event loop, that way the user doesn't have to manually activate the next column.

Simon
centaurzRe: Reaction Improvements20110213 20:13  #2113
@rigo

Then please read the following extract of listbrowser autodoc :


LBRE_EDITTABNEXT - The contents of a node were edited and the
editing session was terminated by pressing [Tab]
. The
application should react by initiating a new editing
session in the next editable column of the gadget if
there is one. Note that you must pass { GA_TabCycle, TRUE }
via LISTBROWSER_EditTags or LBNCA_EditTags for this value
to be returned. (V51)

LBRE_EDITTABPREV - The contents of a node were edited and the
editing session was terminated by pressing [Shift+Tab]
. The
application should react by initiating a new editing
session in the previous editable column of the gadget if
there is one. Note that you must pass { GA_TabCycle, TRUE }
via LISTBROWSER_EditTags or LBNCA_EditTags for this value
to be returned. (V51)



Of course, in our example we didn't catch the LBRE_xxxx code and activate the next cell as suggested, but as the autodoc implies, by supplying GA_TabCycle to the support string gadget, the listbrowser is supposed to copy back the new string to the listbrowser node when you press <TAB>, and indeed that worked nicely with e.g listbrowser V52.3. Otherwise the return codes above are completely useless, who would want to tab-cycle between listbrowser nodes without being able to edit them at the same time ?
rigoRe: Reaction Improvements20110213 20:30  #2115
@centaurz

Hmmm, I'll have to investigate that more, I completely missed that extract in the doc.

Inline editing is not something I've had lots to do with TBH.

I'll have to check the changes from 52.3 onwards. Thanks for reporting.

Simon
TSKRe: Reaction Improvements20110309 20:00  #2793
@rigo

Setting knob size of scroll.gadget. It would be nice if it worked like scroll bars of listbrowser and Workbench drawers. (Full size of viewable area minus one pixel for every notch it can move. Currently it's something different.) I mean the programmer can set which way the size is set.

A new special gadget like that one in IBrowse between vertical and horizontal scrollers. When you click inside that gadget and keep the left button down and move the mouse both scrollers will move simultaneously but mouse pointer stands still until you release the left button.
chrisRe: Reaction Improvements20110326 11:47  #3199
CONTINUED THREAD -->
Navigate: 1-20 21-40 41-60 61-73 
Home
Snack! forum website engine, Created in 2008 by Björn Hagström