Difference: 520KnownIssues (36 vs. 37)

Revision 372012-07-12 - JeanNeron

Line: 1 to 1
 

Known Issues

Table Widget Editor

  • should only accept table source inputs (allowed me to enter a file name) * Fixed *, there was no editting on the fields at all. Made AP & Process name required fields.
Line: 18 to 18
 
  • when adding fields from other files, warning message refers to 'Post User Selection' EP. * Fixed ***
  • Check online help
  • Accepts Invalid field names, accepts invalid occurrence numbers, Does not automatically check app --- if field not found in current app, Scan for field names does not work. * Fixed * There were edits in there, but they were conditioned on --- ERRORS = 0, so once one error occurred, no further editing was done. Created new sub ITEM (EDIT FLD) (TABLESOURCE), based on ITEM (EDIT FLD), which validates field names, occurrences, field types (GROUP fields not allowed), Domains, and checks 0LA if not found in current ap. Replaced all editing with this new routine.
Changed:
<
<
  • Changes made may or may be not logged in SCCS, needs to be tested. Probably shouldn't fix this unless the Design Transfer problem is also fixed. Will likely have a ripple effect in SCCS re: closing tasks, etc.
>
>
  • Changes made may or may be not logged in SCCS, needs to be tested. Probably shouldn't fix this unless the Design Transfer problem is also fixed. Will likely have a ripple effect in SCCS re: closing tasks, etc. * Fixed * Was logging at the PROCESS level, but not the ITEM level. Tested locks, intent locks, color coding, task closing & design xfer.
 
  • Can't change mask if field is not in the current application - * Fixed *
  • Can't run this process via Opt 99. In theory, you should be able to run this process by itself to test your ILF code in SOP, EOP, Post PCF Read, etc. The 0AD INVOC PROC process has no way to invoke a TABLESRC process type, since there is no ILF verb for TABLESRC (as there is for INPUT, OUTPUT, QUERY, etc). Or, to put it another way, we need a TABLESRC ILF command. This will affect the x-ref processes, so they will need to be made aware of this new verb. * Can you do an Opt-97 to build the EM? You can't run a FILE process directly. I'm not sure running a Table Source process standalone has any value. But I could be wrong (pete) * Yes, you can use Opt 97, I added all those helper options to the input. You can always run the input that uses the Table Source to step thru the code, so maybe this could be deferred for later. I was just thinking of consistency, Opt 99 always let's me run a process, even queries (Jean).
Line: 28 to 28
 
  • Filling dead space - right now the last column is expanded –if necessary- to create a row that fills the total with of the table, but that sometimes gives trouble in resizing the last column. ** Fixed **
  • Wide Columns appear to be truncated. Try to display a 512 character field. ** Fixed **
  • If there are compile errors in the Table Source, they are not displayed. Instead the default display for the Table Widget is shown.
Changed:
<
<
  • It seems that rewriting an ITEM (HTM VIEWER) to a table doesn’t work anymore. This is the code in OI:
    SET --- WIDGET NAME = *TBL INF02
    READ --- WIDGET HOLD 1 FT 0 BY WIDGET NAME
    T SET --- WIDGET WIDGET TYPE = TABLE
    T SET --- WIDGET D SRC AP = OTO
    T SET --- WIDGET D SRC INV TYPE = SUBPROCESS
    T SET --- WIDGET D SRC NAME = *TBL INF02
    T REWRITE --- WIDGET FAIL 0
>
>
  • It seems that rewriting an ITEM (HTM VIEWER) to a table doesn’t work anymore. This is the code in OI:
    SET --- WIDGET NAME = *TBL INF02
    READ --- WIDGET HOLD 1 FT 0 BY WIDGET NAME
    T SET --- WIDGET WIDGET TYPE = TABLE
    T SET --- WIDGET D SRC AP = OTO
    T SET --- WIDGET D SRC INV TYPE = SUBPROCESS
    T SET --- WIDGET D SRC NAME = *TBL INF02
    T REWRITE --- WIDGET FAIL 0
 
  • If a field has a size override >80 characters, the table will not display. Fields larger than 80 will display properly if there is no size override.

Drag & Drop Editor

  • There should be a flag on the --- WIDGET spec to indicate if the field can accept a Drop action. This should be available for the following Widget types: button, label, table widget, html viewer, and Window Background. Currently only works for Widgets attached to an item. Problem: Some of those widget types do not fire an option, ie, labels, etc. * Fixed * There is now --- WIDGET DROP TARGET that marks a widget as able to receive a drop action. It also looks at --- WIDGET FI CHOOSE MODE to see what kind of Drop should be supported. --- WIDGET FI CHOOSE MODE has values of ANY, FILE, FOLDER, TREE where ANY is a single file or folder name. Many more widget types now support being a drop target.
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback