[Issue 1] The data file you sent has two cases, both of which are complete. However when I tried to drop into the first case (0010101), CSEntry stops me on form IC1P2 at field PESO_INI1, as no data has been entered, indicating the case is NOT complete. In your logic for PROC R1P112 it checks if R1P112=3 and it skips to R1P114. However, in the PROC PESO_INI1, you have the following logic:
preproc
if ID_ALIMENTO_MEDIDA <> 'NO EXISTE EN EL LAMINARIO'then
PESO_INI1 = ID_PESO
else
PESO_INI1 = R1P113
endif;
[Issue 2]
>I have added the code that you sent, but I have noticed some changes in this regard, before I could
>write directly in the search field and when I hit enter the results that matched the search would
>appear, now after adding the code you must first hit enter to enter to search and filter.
The InAdvance() function was really what I was trying to demonstrate, I didn't mean for it to necessarily be in the layout you wanted, as it depends on what you want to do. To most closely mimic what you were doing before, do this:
preproc
if inAdvance() and length(strip($)) > 0 then
noinput;
endif;
postproc
if selcase("Digite el alimento que busca:", TABLA_DICT,"") <etc>
preproc
if inAdvance() and length(strip($)) > 0 then
noinput;
else
if selcase("Digite el alimento que busca:", TABLA_DICT,"")
<etc>
endif;
endif;
I think you are asking too much of that second repeating record, INC2P1. You could add logic to repeat the fields from the row above when not on row 1, but in your current scenario, you would have to at least enter field R1P101 so you know whether you are entering data for the same ingredient or not. And as you point out, all the information up to field R1P107 must be reentered.
What I would suggest is to create a separate roster for EACH C1P(1-7) item given on form PC1 (the input DCF). Then you could automatically fill the first field, R1P101, for every row, and once they have entered the fields from there to R1P107 on row 1, you can repeat (copy) that data for rows 2-N for all subsequent ingredients. In order to reduce the amount of data fields you're tracking/dealing with (and I'm guessing you'll want to keep the data fields to a minimum for processing/analysis), you'll want to consolidate these food-specific ingredient records into a single record, rather than keeping them spread across 7 records with 10 occurrences each. To do this, save the .csdb file as a .dat file, which will break the connection between the underlying database name and the data fields itself. Then modify the dictionary you have now and use it to reference the .dat file (call it the analysis DCF).
For example, if you allow each C1P(1-7) food to have 10 ingredients, then your input dictionary will have 7 separate IDENTICAL records that have 10 occurrences. Meanwhile your analysis dictionary that will represent the .dat consolidated data file will allow 70 occurrences for the single record INC2P1.
[Issue 4]
On a side note, in both the TABLA_DICT and MC_DE_ALIMENTOS_DICT all but one of the record items (variables) are called "ID_<name>". This hinders review of your application as none of these are ID items, they are just regular dictionary items. If you are using them as a lookup to another dictionary, it would help if they were called something like "LU_ID_<name>", where LU=lookup, so as to clarify your intentions.
Sherrell