Why didn't I get the correct ordinal number, after defining an environment via command "installcounterassociation".
hi, everyone I defined a command to unite counters by the method of defining counters that I saw on other posts. When I wanted to modify the start parameter of the counter, I found that it did not inherit the settings of the current environment, but inherited the settings of the previous environment. For example, in the first chapter, I set the counter for the environment to start counting from 5, but it inherited the original count of 9, and in the second chapter, it inherited the setting from the first chapter, and its counter became 5. The same happens in Chapter 3. Pls can someone fix this? Since the command to unite with the counter is what I found through previous posts and source files, I don't know exactly how it is used. If my question or the mistake I made was too stupid, be sure to let me know. Many thanks. Muyik. %%%% example %%%% I've cut out other parts of the environment that aren't relevant to this issue. \unprotect \installnamespace {material} \installcommandhandler \????material {material} \????material \installcounterassociation {material} \appendtoks \registermaterialcounter\currentmaterial \definecounter[\currentmaterial]% \to \everydefinematerial \appendtoks \synchronizematerialcounters \to \everysetupmaterial \definematerial [material] \definematerial [number] \setupmaterial [\c!title=, \c!author=, \c!source=, \c!start=8,] \setupmaterial [\c!number] [\c!before={(},\c!after={)}, \c!prefix=no,\c!start=9, \c!numberconversion=n, \c!way=\v!by\v!chapter] \def\material_counter_parameter#1% {\begingroup \def\currentmaterial{#1}% \usematerialstyleandcolor\c!style\c!color \namedmaterialparameter\currentmaterial\c!before \convertedcounter[\currentmaterial]% \incrementcounter[\currentmaterial]% \namedmaterialparameter\currentmaterial\c!after \endgroup} \def\startmaterial{\begingroup\dosingleempty\startmaterial_indeed} \def\startmaterial_indeed[#1]{% \iffirstargument\setupcurrentmaterial[#1]\fi \usematerialstyleandcolor\c!style\c!color% \convertedcounter[\currentmaterial]% number seq=(5 3 3) : real num=\material_counter_parameter\c!number => get previous parameter,not right start number\\ number seq=(5 3 3) : real num=\namedmaterialparameter{number}\c!start => get right number\\ material seq=(8 8 8) : real num=\convertedcounter[material] => work well %%%%%%%%%%But I don't want to set the number directly by \setupmaterial, %%%%%%%%%%because there are other elements of this environment, %%%%%%%%%%and they are set by their respective names,like "title" and so on. \incrementcounter[material]} \def\stopmaterial{\par\blackrule% \endgroup} \protect \setuplayout[margin=5mm,width=fit,] \setuphead[chapter][page=no] \starttext \chapter{} \setupmaterial[number][style=tfb,color=red,start=5] \startmaterial \color[gray]{ knuthmath } \stopmaterial \startmaterial \color[gray]{ knuthmath } \stopmaterial \chapter{} \setupmaterial[number][way=bychapter,start=3] \startmaterial \color[gray]{ knuthmath } \stopmaterial \startmaterial \color[gray]{ knuthmath } \stopmaterial \chapter{} \startmaterial \color[gray]{ knuthmath } \stopmaterial \startmaterial \color[gray]{ knuthmath } \stopmaterial \stoptext %%% example
ai2472206007@yeah.net schrieb am 21.10.2024 um 19:26:
hi, everyone
I defined a command to unite counters by the method of defining counters that I saw on other posts. When I wanted to modify the start parameter of the counter, I found that it did not inherit the settings of the current environment, but inherited the settings of the previous environment.
For example, in the first chapter, I set the counter for the environment to start counting from 5, but it inherited the original count of 9,
and in the second chapter, it inherited the setting from the first chapter, and its counter became 5.
The same happens in Chapter 3. Pls can someone fix this?
Since the command to unite with the counter is what I found through previous posts and source files, I don't know exactly how it is used. If my question or the mistake I made was too stupid, be sure to let me know.
When you change the start value of a counter you have to reset the counter, in your case the reset happened at the start of the following chapter which explains the delay. You can try the following example with and without the reset mode. %%%% begin example \definecounter[xxx][way=bychapter,prefix=no] \startbuffer[increment] \incrementcounter[xxx] \convertedcounter[xxx] \stopbuffer %\enablemode[reset] \starttext \dorecurse{2}{\getbuffer[increment]\blank} \startchapter [title={Setting counter value after \tex{chapter}}] \setupcounter[xxx][start=6] \doifmode{reset}{\resetcounter[xxx]} \dorecurse{2}{\getbuffer[increment]\blank} \stopchapter \startchapter [title={Dummy \tex{chapter}}] \dorecurse{2}{\getbuffer[increment]\blank} \setupcounter[xxx][start=4] \doifmode{reset}{\resetcounter[xxx]} \stopchapter \startchapter [title={Setting counter value before \tex{chapter}}] \dorecurse{2}{\getbuffer[increment]\blank} \stopchapter \startchapter [title={Dummy \tex{chapter}}] \dorecurse{2}{\getbuffer[increment]\blank} \stopchapter \stoptext %%%% end example
Many thanks.
Muyik.
%%%% example %%%% I've cut out other parts of the environment that aren't relevant to this issue. \unprotect \installnamespace {material} \installcommandhandler \????material {material} \????material \installcounterassociation {material} \appendtoks \registermaterialcounter\currentmaterial \definecounter[\currentmaterial]% \to \everydefinematerial \appendtoks \synchronizematerialcounters \to \everysetupmaterial
\definematerial [material] \definematerial [number]
\setupmaterial [\c!title=, \c!author=, \c!source=, \c!start=8,]
There is no need to set keys which take empty value because \materialparameter takes care of this and handles keys which haven't been set as empty.
\setupmaterial [\c!number] [\c!before={(},\c!after={)}, \c!prefix=no,\c!start=9, \c!numberconversion=n, \c!way=\v!by\v!chapter]
\def\material_counter_parameter#1% {\begingroup \def\currentmaterial{#1}% \usematerialstyleandcolor\c!style\c!color \namedmaterialparameter\currentmaterial\c!before \convertedcounter[\currentmaterial]% \incrementcounter[\currentmaterial]% \namedmaterialparameter\currentmaterial\c!after \endgroup}
Increment counter value before you output the value and set the start value always 1 below the first number, other counters in ConTeXt use this system and it's good style to follow it.
\def\startmaterial{\begingroup\dosingleempty\startmaterial_indeed} \def\startmaterial_indeed[#1]{% \iffirstargument\setupcurrentmaterial[#1]\fi
You can use the tolerant mechanism to skip the two-step-process to create a command with an optional argument and don't forget to assign a value to \currentmaterial at the start of the environment. \tolerant\protected\def\startmaterial[#1]% {\begingroup \lettonothing\currentmaterial \ifarguments\or \setupcurrentmaterial[#1]% \fi ... Wolfgang
Thank you so much. I think I understand its usage. Also, regarding the "ifargument" command you mentioned, is it counting from 0 and then checking the arguments one by one? Because I only learned "iffirstargument", "ifsecondargument" from the wiki. Perhaps we should update the section on the wiki on defining optional parameters.
ai2472206007@yeah.net schrieb am 22.10.2024 um 07:32:
Thank you so much. I think I understand its usage.
Also, regarding the "ifargument" command you mentioned, is it counting from 0 and then checking the arguments one by one? Because I only learned "iffirstargument", "ifsecondargument" from the wiki. Perhaps we should update the section on the wiki on defining optional parameters.
You can check individual argument with the old and new method but there are differences because the new \ifparameter conditional gives a false result when you set the optional argument but leave it empty. %%%% begin example \def\oldargumentcheck {\dotripleempty\dooldargumentcheck} \def\dooldargumentcheck[#1][#2][#3]% {\iffirstargument First optional argument is used.\par \else First optional argument isn't used.\par \fi \ifsecondargument Second optional argument is used.\par \else Second optional argument isn't used.\par \fi \ifthirdargument Third optional argument is used.\par \else Third optional argument isn't used.\par \fi} \tolerant\def\newargumentcheck[#1][#2][#3]% {\ifparameter#1\or First optional argument is used.\par \else First optional argument isn't used or empty.\par \fi \ifparameter#2\or Second optional argument is used.\par \else Second optional argument isn't used or empty.\par \fi \ifparameter#3\or Third optional argument is used.\par \else Third optional argument isn't used or empty.\par \fi} \starttext \oldargumentcheck[][foo] \blank \newargumentcheck[][bar] \stoptext %%%% end example When you care only about the number of argument you would use nested argument checks in the old system but the new \ifarguments conditional uses branches for each case like \ifcase. The order for the number of arguments is also reversed, the old system starts with the case for all argument and ends with zero arguments while the new check start with zero arguments and ends with all of them. %%%% begin example \def\oldcommand {\dotripleempty\dooldcommand} \def\dooldcommand[#1][#2][#3]% {\ifthirdargument Three optional arguments are used.\par \else\ifsecondargument Two optional arguments are used.\par \else\iffirstargument One optional argument is used.\par \else No optional argument is used.\par \fi\fi\fi} \tolerant\def\newcommand[#1][#2][#3]% {\ifarguments No optional argument is used.\par \or One optional argument is used.\par \or Two optional arguments are used.\par \or Three optional arguments are used.\par \fi} \starttext \oldcommand[][] \blank \newcommand[][] \stoptext %%%% end example Wolfgang
Amazing. There is such a subtle difference between them. Thanks for the explanation. Muyik
participants (2)
-
ai2472206007＠yeah.net -
Wolfgang Schuster