I'd like to add the very obvious one: Setting a breakpoint somewhere and then adding any valid logical condition to this breakpoint through Debug->Edit breakpoints. Example: I set a breakpoint in the read trigger of my TRACK entity. By using the Debug->Edit breakpoints menu, if I enter in the 'Condition' field this condition: track_name='suzuka'|track_name='monza' ...my debugger will only pop up if the application reads the Suzuka or Monza track record.

Hi Gianni, I think your customers are longing for a watchpoint, but uniface provides only breapoints on a specific codeline. 5.1.2 Setting Watchpoints You can use a watchpoint to stop execution whenever the value of an expression changes, without having to predict a particular place where this may happen. (This is sometimes called a data breakpoint.) The expression may be as simple as the value of a single variable, or as complex as many variables combined by operators. Examples include:

• A reference to the value of a single variable.
• An address cast to an appropriate data type. For example, ‘*(int *)0x12345678’ will watch a 4-byte region at the specified address (assuming an
  int
  occupies 4 bytes).
• An arbitrarily complex expression, such as ‘a*b + c/d’. The expression can use any operators valid in the program's native language (see Languages).

Hello Gianni, I think, you are right. There is no way in Uniface debugger to do this. At least as far as I know. Oh, how I wish I was wrong. It brings us a serious head-ache, since everyone just need this feature from time to time. Breakpoints (and what Arjen mentioned) is not very helpful here. If you need to catch (find) a place, where that variable has changed its value or a field or anything... I'm not aware of anyone knowing why Uniface lacks such a basic feature of a debugger... Ok, I don't want to start any flame here, but it would be fine to have this feature. It would save us a lot of time staring at the debugger clicking the "Step Into" button. :-D Zdeněk

Currently the Debugger only provides the possibility to break on a specific Proc Error (see Settings > tab Errors). Daniel

First of all thanks guys for your input! @Arjen: you know I appreciate a lot your talking about Monza or Suzuka :-) but my request come from field real life. Assume you were a support person of a large application and you discover in a field a value of 3 while the valid values are 0,1,2. You have two choices here: 1) Start to reduce the problem and map (reduce and map in this times of map&reduce...ah ah ah :-) ...) those components that could be the culprit then use your tecnique to go further. This path can be applied when the support person has a (deep) knowledge of the large application. 2) If support person does not have a (deep) knowledge of the large application the solution to have a watchpoint (@Uli, thanks to let me learn a new techy term!) is much more efficient and it could possibly be applied also for a specific timeframe to an enduser accepting a slowing down in application response time to enable a bug hunting. @sochaz: thanks for your agreeing to this issue. I will open an item on the wishlist. Gianni

You can do this. I do.  Set a breakpoint and then edit breakpoints, set the condition at the bottom to the test you are interested in "field=3", then delete one or more of the fields line, module and structure.  e.g. to activate within this component only, delete line and module, and leave structure, to activate within the application as a whole remove the structure as well.  Run the app as normal, the debugger will halt when the condition is true. I frequently then add the condition &1=0 to the previous condition to allow me to run ahead a bit without stopping on every line...  The caveat is, if you delete the structure the breakpoint will not save on exit from the debugger, and you have to set it up again for the next run. 

lain: fantastic! Exactly as described! Thanks. Gianni

Just another one, which maybe useful just to check the accesses to variables (direct), without checking the content: $scan($uppercase($item("LIN",($itemnr(1,$proccontext("FULL"))))),"VARIA")>0 works within the condition of the breakpoint as expected. The debugger stops on every place, where "Varia" is used in the proccode. Indirections are not involved. Unfortunetly the condition field in the debugger is limited: Longer Variable names wouldn't fit. In this case you don't need to reset/adapt the condition each time, the value changes. Wolfgang