001/* ---------------------------------------------------------------------------- 002 * This file was automatically generated by SWIG (http://www.swig.org). 003 * Version 3.0.10 004 * 005 * Do not make changes to this file unless you know what you are doing--modify 006 * the SWIG interface file instead. 007 * ----------------------------------------------------------------------------- */ 008 009package org.sbml.libsbml; 010 011/** 012 * <span class="pkg-marker pkg-color-fbc"><a href="group__fbc.html">fbc</a></span> 013 Max or min value for a reaction flux. 014 <p> 015 * The {@link FluxBound} class of objects is used in Version 1 of the SBML 016 * Level 3 <a href='../../../extensions-summary.html#fbc'>Flux Balance Constraints</a> (“fbc”) package to express a single 017 * (in)equality that provides the maximum or minimum value that a reaction 018 * flux can obtain at steady state. (This same information is encoded 019 * differently in Version 2 of “fbc”; see the 020 * 'upperFluxBound' and 'lowerFluxBound' attributes on {@link FbcReactionPlugin}.) 021 <p> 022 * <h2>Attributes on {@link FluxBound}</h2> 023 <p> 024 * In addition to the common optional attributes 'id' and 'name', {@link FluxBound} 025 * takes three required attributes: 'reaction', 'operation' and 'value'. 026 * These three attributes define the meaning of the {@link FluxBound}, and are 027 * interpreted using the following expression: 028 * <center> 029 * <em>reaction</em> <em>operator</em> <em>value</em> 030 * </center> 031 <p> 032 * The 'reaction' attribute takes a value of <code>SIdRef</code>. The value 033 * must be the identifier of a {@link Reaction} object defined within the enclosing 034 * model. 035 <p> 036 * The 'operation' attribute takes a value from an enumeration 037 * (#FluxBoundOperation_t) of Boolean operations that represent mathemetical 038 * inequalities. Possible values for 'operation' include 039 * <code>'greaterEqual'</code>, <code>'equal'</code>, and others. 040 <p> 041 * The 'value' attribute takes a numerical value of type <code>double</code>, 042 * and represents the value of the flux bound. The permitted values include 043 * positive infinity (<code>'INF'</code>) and negative infinity 044 * (<code>'-INF'</code>). 045 <p> 046 * The following is an example of a set of flux bounds encoded in this form; it 047 * also demonstrates the use of {@link ListOfFluxBounds}. 048 <p> 049 * <pre class='fragment'> 050<fbc:listOfFluxBounds> 051 <fbc:fluxBound fbc:id='R1b' fbc:reaction='R1' fbc:operation='greaterEqual' fbc:value='1.2'/> 052 <fbc:fluxBound fbc:id='R2b' fbc:reaction='R2' fbc:operation='lessEqual' fbc:value='-1.2'/> 053 <fbc:fluxBound fbc:id='R3b' fbc:reaction='R3' fbc:operation='greaterEqual' fbc:value='-INF'/> 054 <fbc:fluxBound fbc:id='R4b' fbc:reaction='R4' fbc:operation='lessEqual' fbc:value='INF'/> 055 <fbc:fluxBound fbc:id='R5b' fbc:reaction='R5' fbc:operation='equal' fbc:value='1'/> 056</fbc:listOfFluxBounds> 057</pre> 058 <p> 059 * @note This class is only defined for Version 1 of the 060 * “fbc” package specification. It was replaced in 061 * Version 2 by a {@link Parameter} referenced by the 'upperFluxBound' or 062 * 'lowerFluxBound' attributes on an {@link FbcReactionPlugin}. {@link FluxBound} is 063 * therefore not used for Version 2 “fbc” models. 064 <p> 065 * @see ListOfFluxBounds 066 */ 067 068public class FluxBound extends SBase { 069 private long swigCPtr; 070 071 protected FluxBound(long cPtr, boolean cMemoryOwn) 072 { 073 super(libsbmlJNI.FluxBound_SWIGUpcast(cPtr), cMemoryOwn); 074 swigCPtr = cPtr; 075 } 076 077 protected static long getCPtr(FluxBound obj) 078 { 079 return (obj == null) ? 0 : obj.swigCPtr; 080 } 081 082 protected static long getCPtrAndDisown (FluxBound obj) 083 { 084 long ptr = 0; 085 086 if (obj != null) 087 { 088 ptr = obj.swigCPtr; 089 obj.swigCMemOwn = false; 090 } 091 092 return ptr; 093 } 094 095 protected void finalize() { 096 delete(); 097 } 098 099 public synchronized void delete() { 100 if (swigCPtr != 0) { 101 if (swigCMemOwn) { 102 swigCMemOwn = false; 103 libsbmlJNI.delete_FluxBound(swigCPtr); 104 } 105 swigCPtr = 0; 106 } 107 super.delete(); 108 } 109 110 111/** 112 * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and 113 * “fbc”package version. 114 <p> 115 * @param level a long integer, the SBML Level to assign to this 116 * {@link FluxObjective}. 117 <p> 118 * @param version a long integer, the SBML Version to assign to this 119 * {@link FluxObjective}. 120 <p> 121 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 122 * this {@link FluxObjective}. 123 <p> 124 * <p> 125 * @note Attempting to add an object to an {@link SBMLDocument} having a different 126 * combination of SBML Level, Version and XML namespaces than the object 127 * itself will result in an error at the time a caller attempts to make the 128 * addition. A parent object must have compatible Level, Version and XML 129 * namespaces. (Strictly speaking, a parent may also have more XML 130 * namespaces than a child, but the reverse is not permitted.) The 131 * restriction is necessary to ensure that an SBML model has a consistent 132 * overall structure. This requires callers to manage their objects 133 * carefully, but the benefit is increased flexibility in how models can be 134 * created by permitting callers to create objects bottom-up if desired. In 135 * situations where objects are not yet attached to parents (e.g., 136 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 137 * libSBML determine such things as whether it is valid to assign a 138 * particular value to an attribute. For packages, this means that the 139 * parent object to which this package element is being added must have 140 * been created with the package namespace, or that the package namespace 141 * was added to it, even if that parent is not a package object itself. 142 */ public 143 FluxBound(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException { 144 this(libsbmlJNI.new_FluxBound__SWIG_0(level, version, pkgVersion), true); 145 } 146 147 148/** 149 * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and 150 * “fbc”package version. 151 <p> 152 * @param level a long integer, the SBML Level to assign to this 153 * {@link FluxObjective}. 154 <p> 155 * @param version a long integer, the SBML Version to assign to this 156 * {@link FluxObjective}. 157 <p> 158 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 159 * this {@link FluxObjective}. 160 <p> 161 * <p> 162 * @note Attempting to add an object to an {@link SBMLDocument} having a different 163 * combination of SBML Level, Version and XML namespaces than the object 164 * itself will result in an error at the time a caller attempts to make the 165 * addition. A parent object must have compatible Level, Version and XML 166 * namespaces. (Strictly speaking, a parent may also have more XML 167 * namespaces than a child, but the reverse is not permitted.) The 168 * restriction is necessary to ensure that an SBML model has a consistent 169 * overall structure. This requires callers to manage their objects 170 * carefully, but the benefit is increased flexibility in how models can be 171 * created by permitting callers to create objects bottom-up if desired. In 172 * situations where objects are not yet attached to parents (e.g., 173 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 174 * libSBML determine such things as whether it is valid to assign a 175 * particular value to an attribute. For packages, this means that the 176 * parent object to which this package element is being added must have 177 * been created with the package namespace, or that the package namespace 178 * was added to it, even if that parent is not a package object itself. 179 */ public 180 FluxBound(long level, long version) throws org.sbml.libsbml.SBMLConstructorException { 181 this(libsbmlJNI.new_FluxBound__SWIG_1(level, version), true); 182 } 183 184 185/** 186 * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and 187 * “fbc”package version. 188 <p> 189 * @param level a long integer, the SBML Level to assign to this 190 * {@link FluxObjective}. 191 <p> 192 * @param version a long integer, the SBML Version to assign to this 193 * {@link FluxObjective}. 194 <p> 195 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 196 * this {@link FluxObjective}. 197 <p> 198 * <p> 199 * @note Attempting to add an object to an {@link SBMLDocument} having a different 200 * combination of SBML Level, Version and XML namespaces than the object 201 * itself will result in an error at the time a caller attempts to make the 202 * addition. A parent object must have compatible Level, Version and XML 203 * namespaces. (Strictly speaking, a parent may also have more XML 204 * namespaces than a child, but the reverse is not permitted.) The 205 * restriction is necessary to ensure that an SBML model has a consistent 206 * overall structure. This requires callers to manage their objects 207 * carefully, but the benefit is increased flexibility in how models can be 208 * created by permitting callers to create objects bottom-up if desired. In 209 * situations where objects are not yet attached to parents (e.g., 210 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 211 * libSBML determine such things as whether it is valid to assign a 212 * particular value to an attribute. For packages, this means that the 213 * parent object to which this package element is being added must have 214 * been created with the package namespace, or that the package namespace 215 * was added to it, even if that parent is not a package object itself. 216 */ public 217 FluxBound(long level) throws org.sbml.libsbml.SBMLConstructorException { 218 this(libsbmlJNI.new_FluxBound__SWIG_2(level), true); 219 } 220 221 222/** 223 * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and 224 * “fbc”package version. 225 <p> 226 * @param level a long integer, the SBML Level to assign to this 227 * {@link FluxObjective}. 228 <p> 229 * @param version a long integer, the SBML Version to assign to this 230 * {@link FluxObjective}. 231 <p> 232 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 233 * this {@link FluxObjective}. 234 <p> 235 * <p> 236 * @note Attempting to add an object to an {@link SBMLDocument} having a different 237 * combination of SBML Level, Version and XML namespaces than the object 238 * itself will result in an error at the time a caller attempts to make the 239 * addition. A parent object must have compatible Level, Version and XML 240 * namespaces. (Strictly speaking, a parent may also have more XML 241 * namespaces than a child, but the reverse is not permitted.) The 242 * restriction is necessary to ensure that an SBML model has a consistent 243 * overall structure. This requires callers to manage their objects 244 * carefully, but the benefit is increased flexibility in how models can be 245 * created by permitting callers to create objects bottom-up if desired. In 246 * situations where objects are not yet attached to parents (e.g., 247 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 248 * libSBML determine such things as whether it is valid to assign a 249 * particular value to an attribute. For packages, this means that the 250 * parent object to which this package element is being added must have 251 * been created with the package namespace, or that the package namespace 252 * was added to it, even if that parent is not a package object itself. 253 */ public 254 FluxBound() throws org.sbml.libsbml.SBMLConstructorException { 255 this(libsbmlJNI.new_FluxBound__SWIG_3(), true); 256 } 257 258 259/** 260 * Creates a new {@link FluxBound} with the given {@link FbcPkgNamespaces} object. 261 <p> 262 * <p> 263 * The package namespaces object used in this constructor is derived from a 264 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces 265 * information. It is used to communicate the SBML Level, Version, and 266 * package version and name information used in addition to SBML Level 3 Core. A 267 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an 268 * package namespace object somewhere in a program once, then hand that object 269 * as needed to object constructors of that package that accept it as and 270 * argument, such as this one. 271 <p> 272 * @param fbcns the {@link FbcPkgNamespaces} object. 273 <p> 274 * <p> 275 * @note Attempting to add an object to an {@link SBMLDocument} having a different 276 * combination of SBML Level, Version and XML namespaces than the object 277 * itself will result in an error at the time a caller attempts to make the 278 * addition. A parent object must have compatible Level, Version and XML 279 * namespaces. (Strictly speaking, a parent may also have more XML 280 * namespaces than a child, but the reverse is not permitted.) The 281 * restriction is necessary to ensure that an SBML model has a consistent 282 * overall structure. This requires callers to manage their objects 283 * carefully, but the benefit is increased flexibility in how models can be 284 * created by permitting callers to create objects bottom-up if desired. In 285 * situations where objects are not yet attached to parents (e.g., 286 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 287 * libSBML determine such things as whether it is valid to assign a 288 * particular value to an attribute. For packages, this means that the 289 * parent object to which this package element is being added must have 290 * been created with the package namespace, or that the package namespace 291 * was added to it, even if that parent is not a package object itself. 292 */ public 293 FluxBound(FbcPkgNamespaces fbcns) throws org.sbml.libsbml.SBMLConstructorException { 294 this(libsbmlJNI.new_FluxBound__SWIG_4(FbcPkgNamespaces.getCPtr(fbcns), fbcns), true); 295 } 296 297 298/** 299 * Copy constructor. 300 <p> 301 * @param source the instance to copy. 302 */ public 303 FluxBound(FluxBound source) throws org.sbml.libsbml.SBMLConstructorException { 304 this(libsbmlJNI.new_FluxBound__SWIG_5(FluxBound.getCPtr(source), source), true); 305 } 306 307 308/** 309 * Returns the value of the 'id' attribute of this {@link FluxBound}. 310 <p> 311 * @note Because of the inconsistent behavior of this function with 312 * respect to assignments and rules, it is now recommended to 313 * use the getIdAttribute() function instead. 314 <p> 315 * <p> 316 * The identifier given by an object's 'id' attribute value 317 * is used to identify the object within the SBML model definition. 318 * Other objects can refer to the component using this identifier. The 319 * data type of 'id' is always <code>SId</code> or a type derived 320 * from that, such as <code>UnitSId</code>, depending on the object in 321 * question. All data types are defined as follows: 322 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 323 * letter .= 'a'..'z','A'..'Z' 324 * digit .= '0'..'9' 325 * idChar .= letter | digit | '_' 326 * SId .= ( letter | '_' ) idChar* 327 * </pre> 328 <p> 329 * The characters <code>(</code> and <code>)</code> are used for grouping, the 330 * character <code>*</code> 'zero or more times', and the character 331 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 332 * determined by an exact character sequence match; i.e., comparisons must be 333 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 334 * <code>SIdRef</code>, and derived types. 335 <p> 336 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 337 * moved to {@link SBase} directly, instead of being defined individually for many 338 * (but not all) objects. Libsbml has for a long time provided functions 339 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 340 * would fail or otherwise return empty strings if executed on any object 341 * for which those attributes were not defined. Now that all {@link SBase} objects 342 * define those attributes, those functions now succeed for any object with 343 * the appropriate level and version. 344 <p> 345 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 346 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 347 * functions (though not the setId() or unsetId() functions) would instead 348 * reference the value of the 'variable' attribute (for the rules and event 349 * assignments) or the 'symbol' attribute (for initial assignments). 350 * The {@link AlgebraicRule} fell into this category as well, though because it 351 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 352 * always return an empty string, and isSetId() would always return <code>false.</code> 353 * For this reason, four new functions are now provided 354 * (getIdAttribute(), setIdAttribute(String), 355 * isSetIdAttribute(), and unsetIdAttribute()) that will always 356 * act on the actual 'id' attribute, regardless of the object's type. The 357 * new functions should be used instead of the old ones unless the old behavior 358 * is somehow necessary. 359 <p> 360 * Regardless of the level and version of the SBML, these functions allow 361 * client applications to use more generalized code in some situations 362 * (for instance, when manipulating objects that are all known to have 363 * identifiers). If the object in question does not posess an 'id' attribute 364 * according to the SBML specification for the Level and Version in use, 365 * libSBML will not allow the identifier to be set, nor will it read or 366 * write 'id' attributes for those objects. 367 <p> 368 * @return the id of this {@link FluxBound}. 369 <p> 370 * @see #getIdAttribute() 371 * @see #setIdAttribute(String sid) 372 * @see #isSetIdAttribute() 373 * @see #unsetIdAttribute() 374 */ public 375 String getId() { 376 return libsbmlJNI.FluxBound_getId(swigCPtr, this); 377 } 378 379 380/** 381 * Predicate returning <code>true</code> if this {@link FluxBound}'s 'id' attribute is set. 382 <p> 383 * <p> 384 * @note Because of the inconsistent behavior of this function with 385 * respect to assignments and rules, it is now recommended to 386 * use the isSetIdAttribute() function instead. 387 <p> 388 * <p> 389 * The identifier given by an object's 'id' attribute value 390 * is used to identify the object within the SBML model definition. 391 * Other objects can refer to the component using this identifier. The 392 * data type of 'id' is always <code>SId</code> or a type derived 393 * from that, such as <code>UnitSId</code>, depending on the object in 394 * question. All data types are defined as follows: 395 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 396 * letter .= 'a'..'z','A'..'Z' 397 * digit .= '0'..'9' 398 * idChar .= letter | digit | '_' 399 * SId .= ( letter | '_' ) idChar* 400 * </pre> 401 <p> 402 * The characters <code>(</code> and <code>)</code> are used for grouping, the 403 * character <code>*</code> 'zero or more times', and the character 404 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 405 * determined by an exact character sequence match; i.e., comparisons must be 406 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 407 * <code>SIdRef</code>, and derived types. 408 <p> 409 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 410 * moved to {@link SBase} directly, instead of being defined individually for many 411 * (but not all) objects. Libsbml has for a long time provided functions 412 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 413 * would fail or otherwise return empty strings if executed on any object 414 * for which those attributes were not defined. Now that all {@link SBase} objects 415 * define those attributes, those functions now succeed for any object with 416 * the appropriate level and version. 417 <p> 418 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 419 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 420 * functions (though not the setId() or unsetId() functions) would instead 421 * reference the value of the 'variable' attribute (for the rules and event 422 * assignments) or the 'symbol' attribute (for initial assignments). 423 * The {@link AlgebraicRule} fell into this category as well, though because it 424 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 425 * always return an empty string, and isSetId() would always return <code>false.</code> 426 * For this reason, four new functions are now provided 427 * (getIdAttribute(), setIdAttribute(String), 428 * isSetIdAttribute(), and unsetIdAttribute()) that will always 429 * act on the actual 'id' attribute, regardless of the object's type. The 430 * new functions should be used instead of the old ones unless the old behavior 431 * is somehow necessary. 432 <p> 433 * Regardless of the level and version of the SBML, these functions allow 434 * client applications to use more generalized code in some situations 435 * (for instance, when manipulating objects that are all known to have 436 * identifiers). If the object in question does not posess an 'id' attribute 437 * according to the SBML specification for the Level and Version in use, 438 * libSBML will not allow the identifier to be set, nor will it read or 439 * write 'id' attributes for those objects. 440 <p> 441 * @return <code>true</code> if the 'id' attribute of this SBML object is 442 * set, <code>false</code> otherwise. 443 <p> 444 * @see #getIdAttribute() 445 * @see #setIdAttribute(String sid) 446 * @see #unsetIdAttribute() 447 * @see #isSetIdAttribute() 448 */ public 449 boolean isSetId() { 450 return libsbmlJNI.FluxBound_isSetId(swigCPtr, this); 451 } 452 453 454/** 455 * Sets the value of the 'id' attribute of this {@link FluxBound}. 456 <p> 457 * <p> 458 * The string <code>sid</code> is copied. 459 <p> 460 * <p> 461 * The identifier given by an object's 'id' attribute value 462 * is used to identify the object within the SBML model definition. 463 * Other objects can refer to the component using this identifier. The 464 * data type of 'id' is always <code>SId</code> or a type derived 465 * from that, such as <code>UnitSId</code>, depending on the object in 466 * question. All data types are defined as follows: 467 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 468 * letter .= 'a'..'z','A'..'Z' 469 * digit .= '0'..'9' 470 * idChar .= letter | digit | '_' 471 * SId .= ( letter | '_' ) idChar* 472 * </pre> 473 <p> 474 * The characters <code>(</code> and <code>)</code> are used for grouping, the 475 * character <code>*</code> 'zero or more times', and the character 476 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 477 * determined by an exact character sequence match; i.e., comparisons must be 478 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 479 * <code>SIdRef</code>, and derived types. 480 <p> 481 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 482 * moved to {@link SBase} directly, instead of being defined individually for many 483 * (but not all) objects. Libsbml has for a long time provided functions 484 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 485 * would fail or otherwise return empty strings if executed on any object 486 * for which those attributes were not defined. Now that all {@link SBase} objects 487 * define those attributes, those functions now succeed for any object with 488 * the appropriate level and version. 489 <p> 490 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 491 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 492 * functions (though not the setId() or unsetId() functions) would instead 493 * reference the value of the 'variable' attribute (for the rules and event 494 * assignments) or the 'symbol' attribute (for initial assignments). 495 * The {@link AlgebraicRule} fell into this category as well, though because it 496 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 497 * always return an empty string, and isSetId() would always return <code>false.</code> 498 * For this reason, four new functions are now provided 499 * (getIdAttribute(), setIdAttribute(String), 500 * isSetIdAttribute(), and unsetIdAttribute()) that will always 501 * act on the actual 'id' attribute, regardless of the object's type. The 502 * new functions should be used instead of the old ones unless the old behavior 503 * is somehow necessary. 504 <p> 505 * Regardless of the level and version of the SBML, these functions allow 506 * client applications to use more generalized code in some situations 507 * (for instance, when manipulating objects that are all known to have 508 * identifiers). If the object in question does not posess an 'id' attribute 509 * according to the SBML specification for the Level and Version in use, 510 * libSBML will not allow the identifier to be set, nor will it read or 511 * write 'id' attributes for those objects. 512 <p> 513 * @param sid the string to use as the identifier of this object. 514 <p> 515 * <p> 516 * @return integer value indicating success/failure of the 517 * function. The possible values 518 * returned by this function are: 519 * <ul> 520 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 521 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 522 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE} 523 * 524 * </ul> <p> 525 * @see #getIdAttribute() 526 * @see #setIdAttribute(String sid) 527 * @see #isSetIdAttribute() 528 * @see #unsetIdAttribute() 529 */ public 530 int setId(String sid) { 531 return libsbmlJNI.FluxBound_setId(swigCPtr, this, sid); 532 } 533 534 535/** 536 * Unsets the value of the 'id' attribute of this {@link FluxBound} object. 537 <p> 538 * <p> 539 * <p> 540 * The identifier given by an object's 'id' attribute value 541 * is used to identify the object within the SBML model definition. 542 * Other objects can refer to the component using this identifier. The 543 * data type of 'id' is always <code>SId</code> or a type derived 544 * from that, such as <code>UnitSId</code>, depending on the object in 545 * question. All data types are defined as follows: 546 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 547 * letter .= 'a'..'z','A'..'Z' 548 * digit .= '0'..'9' 549 * idChar .= letter | digit | '_' 550 * SId .= ( letter | '_' ) idChar* 551 * </pre> 552 <p> 553 * The characters <code>(</code> and <code>)</code> are used for grouping, the 554 * character <code>*</code> 'zero or more times', and the character 555 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 556 * determined by an exact character sequence match; i.e., comparisons must be 557 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 558 * <code>SIdRef</code>, and derived types. 559 <p> 560 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 561 * moved to {@link SBase} directly, instead of being defined individually for many 562 * (but not all) objects. Libsbml has for a long time provided functions 563 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 564 * would fail or otherwise return empty strings if executed on any object 565 * for which those attributes were not defined. Now that all {@link SBase} objects 566 * define those attributes, those functions now succeed for any object with 567 * the appropriate level and version. 568 <p> 569 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 570 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 571 * functions (though not the setId() or unsetId() functions) would instead 572 * reference the value of the 'variable' attribute (for the rules and event 573 * assignments) or the 'symbol' attribute (for initial assignments). 574 * The {@link AlgebraicRule} fell into this category as well, though because it 575 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 576 * always return an empty string, and isSetId() would always return <code>false.</code> 577 * For this reason, four new functions are now provided 578 * (getIdAttribute(), setIdAttribute(String), 579 * isSetIdAttribute(), and unsetIdAttribute()) that will always 580 * act on the actual 'id' attribute, regardless of the object's type. The 581 * new functions should be used instead of the old ones unless the old behavior 582 * is somehow necessary. 583 <p> 584 * Regardless of the level and version of the SBML, these functions allow 585 * client applications to use more generalized code in some situations 586 * (for instance, when manipulating objects that are all known to have 587 * identifiers). If the object in question does not posess an 'id' attribute 588 * according to the SBML specification for the Level and Version in use, 589 * libSBML will not allow the identifier to be set, nor will it read or 590 * write 'id' attributes for those objects. 591 <p> 592 * <p> 593 * @return integer value indicating success/failure of the 594 * function. The possible values 595 * returned by this function are: 596 * <ul> 597 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 598 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 599 * 600 * </ul> <p> 601 * @see #getIdAttribute() 602 * @see #setIdAttribute(String sid) 603 * @see #isSetIdAttribute() 604 * @see #unsetIdAttribute() 605 */ public 606 int unsetId() { 607 return libsbmlJNI.FluxBound_unsetId(swigCPtr, this); 608 } 609 610 611/** 612 * Returns the value of the 'name' attribute of this {@link FluxBound} object. 613 <p> 614 * <p> 615 * <p> 616 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 617 * moved to {@link SBase} directly, instead of being defined individually for many 618 * (but not all) objects. Libsbml has for a long time provided functions 619 * defined on {@link SBase} itself to get, set, and unset those attributes, which 620 * would fail or otherwise return empty strings if executed on any object 621 * for which those attributes were not defined. Now that all {@link SBase} objects 622 * define those attributes, those functions now succeed for any object with 623 * the appropriate level and version. 624 <p> 625 * The 'name' attribute is 626 * optional and is not intended to be used for cross-referencing purposes 627 * within a model. Its purpose instead is to provide a human-readable 628 * label for the component. The data type of 'name' is the type 629 * <code>string</code> defined in XML Schema. SBML imposes no 630 * restrictions as to the content of 'name' attributes beyond those 631 * restrictions defined by the <code>string</code> type in XML Schema. 632 <p> 633 * The recommended practice for handling 'name' is as follows. If a 634 * software tool has the capability for displaying the content of 'name' 635 * attributes, it should display this content to the user as a 636 * component's label instead of the component's 'id'. If the user 637 * interface does not have this capability (e.g., because it cannot 638 * display or use special characters in symbol names), or if the 'name' 639 * attribute is missing on a given component, then the user interface 640 * should display the value of the 'id' attribute instead. (Script 641 * language interpreters are especially likely to display 'id' instead of 642 * 'name'.) 643 <p> 644 * As a consequence of the above, authors of systems that automatically 645 * generate the values of 'id' attributes should be aware some systems 646 * may display the 'id''s to the user. Authors therefore may wish to 647 * take some care to have their software create 'id' values that are: (a) 648 * reasonably easy for humans to type and read; and (b) likely to be 649 * meaningful, for example by making the 'id' attribute be an abbreviated 650 * form of the name attribute value. 651 <p> 652 * An additional point worth mentioning is although there are 653 * restrictions on the uniqueness of 'id' values, there are no 654 * restrictions on the uniqueness of 'name' values in a model. This 655 * allows software applications leeway in assigning component identifiers. 656 <p> 657 * Regardless of the level and version of the SBML, these functions allow 658 * client applications to use more generalized code in some situations 659 * (for instance, when manipulating objects that are all known to have 660 * names). If the object in question does not posess a 'name' attribute 661 * according to the SBML specification for the Level and Version in use, 662 * libSBML will not allow the name to be set, nor will it read or 663 * write 'name' attributes for those objects. 664 <p> 665 * @return the name of this SBML object, or the empty string if not set or unsettable. 666 <p> 667 * @see #getIdAttribute() 668 * @see #isSetName() 669 * @see #setName(String sid) 670 * @see #unsetName() 671 */ public 672 String getName() { 673 return libsbmlJNI.FluxBound_getName(swigCPtr, this); 674 } 675 676 677/** 678 * Predicate returning <code>true</code> if this {@link FluxBound}'s 'name' attribute is set. 679 <p> 680 * <p> 681 * <p> 682 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 683 * moved to {@link SBase} directly, instead of being defined individually for many 684 * (but not all) objects. Libsbml has for a long time provided functions 685 * defined on {@link SBase} itself to get, set, and unset those attributes, which 686 * would fail or otherwise return empty strings if executed on any object 687 * for which those attributes were not defined. Now that all {@link SBase} objects 688 * define those attributes, those functions now succeed for any object with 689 * the appropriate level and version. 690 <p> 691 * The 'name' attribute is 692 * optional and is not intended to be used for cross-referencing purposes 693 * within a model. Its purpose instead is to provide a human-readable 694 * label for the component. The data type of 'name' is the type 695 * <code>string</code> defined in XML Schema. SBML imposes no 696 * restrictions as to the content of 'name' attributes beyond those 697 * restrictions defined by the <code>string</code> type in XML Schema. 698 <p> 699 * The recommended practice for handling 'name' is as follows. If a 700 * software tool has the capability for displaying the content of 'name' 701 * attributes, it should display this content to the user as a 702 * component's label instead of the component's 'id'. If the user 703 * interface does not have this capability (e.g., because it cannot 704 * display or use special characters in symbol names), or if the 'name' 705 * attribute is missing on a given component, then the user interface 706 * should display the value of the 'id' attribute instead. (Script 707 * language interpreters are especially likely to display 'id' instead of 708 * 'name'.) 709 <p> 710 * As a consequence of the above, authors of systems that automatically 711 * generate the values of 'id' attributes should be aware some systems 712 * may display the 'id''s to the user. Authors therefore may wish to 713 * take some care to have their software create 'id' values that are: (a) 714 * reasonably easy for humans to type and read; and (b) likely to be 715 * meaningful, for example by making the 'id' attribute be an abbreviated 716 * form of the name attribute value. 717 <p> 718 * An additional point worth mentioning is although there are 719 * restrictions on the uniqueness of 'id' values, there are no 720 * restrictions on the uniqueness of 'name' values in a model. This 721 * allows software applications leeway in assigning component identifiers. 722 <p> 723 * Regardless of the level and version of the SBML, these functions allow 724 * client applications to use more generalized code in some situations 725 * (for instance, when manipulating objects that are all known to have 726 * names). If the object in question does not posess a 'name' attribute 727 * according to the SBML specification for the Level and Version in use, 728 * libSBML will not allow the name to be set, nor will it read or 729 * write 'name' attributes for those objects. 730 <p> 731 * @return <code>true</code> if the 'name' attribute of this SBML object is 732 * set, <code>false</code> otherwise. 733 <p> 734 * @see #getName() 735 * @see #setName(String sid) 736 * @see #unsetName() 737 */ public 738 boolean isSetName() { 739 return libsbmlJNI.FluxBound_isSetName(swigCPtr, this); 740 } 741 742 743/** 744 * Sets the value of the 'name' attribute of this {@link FluxBound}. 745 <p> 746 * <p> 747 * The string in <code>name</code> is copied. 748 <p> 749 * @param name the new name for the SBML object. 750 <p> 751 * <p> 752 * @return integer value indicating success/failure of the 753 * function. The possible values 754 * returned by this function are: 755 * <ul> 756 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 757 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 758 * 759 * </ul> 760 */ public 761 int setName(String name) { 762 return libsbmlJNI.FluxBound_setName(swigCPtr, this, name); 763 } 764 765 766/** 767 * Unsets the value of the 'name' attribute of this {@link FluxBound} object. 768 <p> 769 * <p> 770 * <p> 771 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 772 * moved to {@link SBase} directly, instead of being defined individually for many 773 * (but not all) objects. Libsbml has for a long time provided functions 774 * defined on {@link SBase} itself to get, set, and unset those attributes, which 775 * would fail or otherwise return empty strings if executed on any object 776 * for which those attributes were not defined. Now that all {@link SBase} objects 777 * define those attributes, those functions now succeed for any object with 778 * the appropriate level and version. 779 <p> 780 * The 'name' attribute is 781 * optional and is not intended to be used for cross-referencing purposes 782 * within a model. Its purpose instead is to provide a human-readable 783 * label for the component. The data type of 'name' is the type 784 * <code>string</code> defined in XML Schema. SBML imposes no 785 * restrictions as to the content of 'name' attributes beyond those 786 * restrictions defined by the <code>string</code> type in XML Schema. 787 <p> 788 * The recommended practice for handling 'name' is as follows. If a 789 * software tool has the capability for displaying the content of 'name' 790 * attributes, it should display this content to the user as a 791 * component's label instead of the component's 'id'. If the user 792 * interface does not have this capability (e.g., because it cannot 793 * display or use special characters in symbol names), or if the 'name' 794 * attribute is missing on a given component, then the user interface 795 * should display the value of the 'id' attribute instead. (Script 796 * language interpreters are especially likely to display 'id' instead of 797 * 'name'.) 798 <p> 799 * As a consequence of the above, authors of systems that automatically 800 * generate the values of 'id' attributes should be aware some systems 801 * may display the 'id''s to the user. Authors therefore may wish to 802 * take some care to have their software create 'id' values that are: (a) 803 * reasonably easy for humans to type and read; and (b) likely to be 804 * meaningful, for example by making the 'id' attribute be an abbreviated 805 * form of the name attribute value. 806 <p> 807 * An additional point worth mentioning is although there are 808 * restrictions on the uniqueness of 'id' values, there are no 809 * restrictions on the uniqueness of 'name' values in a model. This 810 * allows software applications leeway in assigning component identifiers. 811 <p> 812 * Regardless of the level and version of the SBML, these functions allow 813 * client applications to use more generalized code in some situations 814 * (for instance, when manipulating objects that are all known to have 815 * names). If the object in question does not posess a 'name' attribute 816 * according to the SBML specification for the Level and Version in use, 817 * libSBML will not allow the name to be set, nor will it read or 818 * write 'name' attributes for those objects. 819 <p> 820 * <p> 821 * @return integer value indicating success/failure of the 822 * function. The possible values 823 * returned by this function are: 824 * <ul> 825 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 826 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 827 * 828 * </ul> <p> 829 * @see #getName() 830 * @see #setName(String sid) 831 * @see #isSetName() 832 */ public 833 int unsetName() { 834 return libsbmlJNI.FluxBound_unsetName(swigCPtr, this); 835 } 836 837 838/** 839 * Returns the value of the 'reaction' attribute of this {@link FluxBound} object. 840 <p> 841 * @return the value of the 'reaction' attribute of this {@link FluxBound} object. 842 */ public 843 String getReaction() { 844 return libsbmlJNI.FluxBound_getReaction(swigCPtr, this); 845 } 846 847 848/** 849 * Predicate returning <code>true</code> if this {@link FluxBound}'s 'reaction' attribute is 850 * set. 851 <p> 852 * @return <code>true</code> if this {@link FluxBound} object's 'reaction' attribute has been 853 * set, otherwise <code>false</code> is returned. 854 */ public 855 boolean isSetReaction() { 856 return libsbmlJNI.FluxBound_isSetReaction(swigCPtr, this); 857 } 858 859 860/** 861 * Sets the value of the 'reaction' attribute of this {@link FluxBound} object. 862 <p> 863 * <p> 864 * @return integer value indicating success/failure of the 865 * function. The possible values 866 * returned by this function are: 867 * <ul> 868 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 869 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 870 * </ul> 871 */ public 872 int setReaction(String reaction) { 873 return libsbmlJNI.FluxBound_setReaction(swigCPtr, this, reaction); 874 } 875 876 877/** 878 * Unsets the value of the 'reaction' attribute of this {@link FluxBound} object. 879 <p> 880 * <p> 881 * @return integer value indicating success/failure of the 882 * function. The possible values 883 * returned by this function are: 884 * <ul> 885 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 886 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 887 * </ul> 888 */ public 889 int unsetReaction() { 890 return libsbmlJNI.FluxBound_unsetReaction(swigCPtr, this); 891 } 892 893 894/** 895 * Returns the value of the 'operation' attribute of this {@link FluxBound} object. 896 <p> 897 * @return the value of the 'operation' attribute of this {@link FluxBound} object. 898 */ public 899 String getOperation() { 900 return libsbmlJNI.FluxBound_getOperation(swigCPtr, this); 901 } 902 903 904/** 905 * Returns the value of the 'operation' attribute of this {@link FluxBound} object. 906 <p> 907 * @return the value of the 'operation' attribute of this {@link FluxBound} object. 908 */ public 909 int getFluxBoundOperation() { 910 return libsbmlJNI.FluxBound_getFluxBoundOperation(swigCPtr, this); 911 } 912 913 914/** 915 * Predicate returning <code>true</code> if this {@link FluxBound}'s 'operation' attribute is 916 * set. 917 <p> 918 * @return <code>true</code> if this {@link FluxBound} object's 'operation' attribute has been set, 919 * otherwise <code>false</code> is returned. 920 */ public 921 boolean isSetOperation() { 922 return libsbmlJNI.FluxBound_isSetOperation(swigCPtr, this); 923 } 924 925 926/** 927 * Sets the value of the 'operation' attribute of this {@link FluxBound} object. 928 <p> 929 * <p> 930 * @return integer value indicating success/failure of the 931 * function. The possible values 932 * returned by this function are: 933 * <ul> 934 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 935 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 936 * </ul> 937 */ public 938 int setOperation(String operation) { 939 return libsbmlJNI.FluxBound_setOperation__SWIG_0(swigCPtr, this, operation); 940 } 941 942 943/** 944 * Sets the value of the 'operation' attribute of this {@link FluxBound} object. 945 <p> 946 * <p> 947 * @return integer value indicating success/failure of the 948 * function. The possible values 949 * returned by this function are: 950 * <ul> 951 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 952 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 953 * </ul> 954 */ public 955 int setOperation(int operation) { 956 return libsbmlJNI.FluxBound_setOperation__SWIG_1(swigCPtr, this, operation); 957 } 958 959 960/** 961 * Unsets the value of the 'operation' attribute of this {@link FluxBound} object. 962 <p> 963 * <p> 964 * @return integer value indicating success/failure of the 965 * function. The possible values 966 * returned by this function are: 967 * <ul> 968 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 969 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 970 * </ul> 971 */ public 972 int unsetOperation() { 973 return libsbmlJNI.FluxBound_unsetOperation(swigCPtr, this); 974 } 975 976 977/** 978 * Returns the value of the 'value' attribute of this {@link FluxBound} object. 979 <p> 980 * @return the value of the 'value' attribute of this {@link FluxBound} object. 981 */ public 982 double getValue() { 983 return libsbmlJNI.FluxBound_getValue(swigCPtr, this); 984 } 985 986 987/** 988 * Predicate returning <code>true</code> if this {@link FluxBound}'s 'value' attribute is 989 * set. 990 <p> 991 * @return <code>true</code> if this {@link FluxBound} object's 'value' attribute has been set, 992 * otherwise <code>false</code> is returned. 993 */ public 994 boolean isSetValue() { 995 return libsbmlJNI.FluxBound_isSetValue(swigCPtr, this); 996 } 997 998 999/** 1000 * Sets the value of the 'value' attribute of this {@link FluxBound} object. 1001 <p> 1002 * <p> 1003 * @return integer value indicating success/failure of the 1004 * function. The possible values 1005 * returned by this function are: 1006 * <ul> 1007 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 1008 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 1009 * </ul> 1010 */ public 1011 int setValue(double value) { 1012 return libsbmlJNI.FluxBound_setValue(swigCPtr, this, value); 1013 } 1014 1015 1016/** 1017 * Unsets the value of the 'value' attribute of this {@link FluxBound} object. 1018 <p> 1019 * <p> 1020 * @return integer value indicating success/failure of the 1021 * function. The possible values 1022 * returned by this function are: 1023 * <ul> 1024 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 1025 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 1026 * </ul> 1027 */ public 1028 int unsetValue() { 1029 return libsbmlJNI.FluxBound_unsetValue(swigCPtr, this); 1030 } 1031 1032 1033/** 1034 * <p> 1035 * Replaces all uses of a given <code>SIdRef</code> type attribute value with another 1036 * value. 1037 <p> 1038 * <p> 1039 * In SBML, object identifiers are of a data type called <code>SId</code>. 1040 * In SBML Level 3, an explicit data type called <code>SIdRef</code> was 1041 * introduced for attribute values that refer to <code>SId</code> values; in 1042 * previous Levels of SBML, this data type did not exist and attributes were 1043 * simply described to as 'referring to an identifier', but the effective 1044 * data type was the same as <code>SIdRef</code> in Level 3. These and 1045 * other methods of libSBML refer to the type <code>SIdRef</code> for all 1046 * Levels of SBML, even if the corresponding SBML specification did not 1047 * explicitly name the data type. 1048 <p> 1049 * This method works by looking at all attributes and (if appropriate) 1050 * mathematical formulas in MathML content, comparing the referenced 1051 * identifiers to the value of <code>oldid</code>. If any matches are found, the 1052 * matching values are replaced with <code>newid</code>. The method does <em>not</em> 1053 * descend into child elements. 1054 <p> 1055 * @param oldid the old identifier. 1056 * @param newid the new identifier. 1057 */ public 1058 void renameSIdRefs(String oldid, String newid) { 1059 libsbmlJNI.FluxBound_renameSIdRefs(swigCPtr, this, oldid, newid); 1060 } 1061 1062 1063/** 1064 * Returns the XML element name of this object. 1065 <p> 1066 * For {@link FluxBound}, the XML element name is always <code>'fluxBound'.</code> 1067 <p> 1068 * @return the name of this element, i.e. <code>'fluxBound'.</code> 1069 */ public 1070 String getElementName() { 1071 return libsbmlJNI.FluxBound_getElementName(swigCPtr, this); 1072 } 1073 1074 1075/** 1076 * Creates and returns a deep copy of this {@link FluxBound} object. 1077 <p> 1078 * @return a (deep) copy of this {@link FluxBound} object. 1079 */ public 1080 FluxBound cloneObject() { 1081 long cPtr = libsbmlJNI.FluxBound_cloneObject(swigCPtr, this); 1082 return (cPtr == 0) ? null : new FluxBound(cPtr, true); 1083 } 1084 1085 1086/** 1087 * Returns the libSBML type code of this object instance. 1088 <p> 1089 * <p> 1090 * LibSBML attaches an identifying code to every kind of SBML object. These 1091 * are integer constants known as <em>SBML type codes</em>. The names of all 1092 * the codes begin with the characters <code>SBML_</code>. 1093 * In the Java language interface for libSBML, the 1094 * type codes are defined as static integer constants in the interface class 1095 * {@link libsbmlConstants}. Note that different Level 3 1096 * package plug-ins may use overlapping type codes; to identify the package 1097 * to which a given object belongs, call the <code>getPackageName()</code> 1098 * method on the object. 1099 <p> 1100 * @return the SBML type code for this object: 1101 * {@link libsbmlConstants#SBML_FBC_FLUXBOUND SBML_FBC_FLUXBOUND}. 1102 <p> 1103 * <p> 1104 * @warning <span class='warning'>The specific integer values of the possible 1105 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 1106 * packages, To fully identify the correct code, <strong>it is necessary to 1107 * invoke both getTypeCode() and getPackageName()</strong>.</span> 1108 <p> 1109 * @see #getElementName() 1110 * @see #getPackageName() 1111 */ public 1112 int getTypeCode() { 1113 return libsbmlJNI.FluxBound_getTypeCode(swigCPtr, this); 1114 } 1115 1116 1117/** * @internal */ public 1118 void enablePackageInternal(String pkgURI, String pkgPrefix, boolean flag) { 1119 libsbmlJNI.FluxBound_enablePackageInternal(swigCPtr, this, pkgURI, pkgPrefix, flag); 1120 } 1121 1122}