Hi, That is great. Do you think it duplicates https://lists.apache.org/thread/1mplrt4bqd6h08kj38hkvxwy527nckpn ?
>Disable post processor (when extracting value from home page, there is >no need to consume CPU with each iteration to get the same value ) Currently, JMeter ignores disabled elements forever, and it never re-evaluates enabled-disabled state during execution. If you really want to make "is element disabled" check dynamic, it would be not that easy. Frankly speaking, adding a **text field** just for disabling elements looks like overcomplicating UI for an infrequent feature. On the other hand, a smaller "enabled" checkbox might be OK. What do you think of the following? a) Making a "smart checkbox" Swing component that looks like a checkbox, however it has an extra "button" (or something) to convert the checkbox into text field. Then all JMeter sampler and plugins could use that checkbox to make "boolean-like" properties configuration consistent across the UI b) Implementing a special "element.Thread Group Name.Transaction Name.Sampler Name.enabled=true" property syntax that would allow overriding element properties from a command line. Of course, component names can drift over time, so it might make sense to add a notion of "element ID" that would be persistent across load/save operations. The syntax then could be like element.82f0e0cd-ee42-49db-a0ec-b8b9c6cb8bc1(comment-here).enabled=false or even element.7c3161d9-ade9-4f82-b183-308774149a78(user-search-thread-group).ThreadGroup.num_threads=42 The comment in braces would be ignored, and it would be there just for the humans to understand the intention of the property. Do you think you could work on those features? Vladimir
