Debugger Irritants

[soa]

A couple of things that drive me crazy everyday!

When debugging WAMs right-cliking a variable name in the code does bring up the 'Show variable' in the popup menu like it does in other RDMLX functions forcing me to trawl through the variable list.

In the list of debug variables anything with a field name longer than 9 characters is jammed up at the top and not in alphabetical order with the other variables. So you have DATESTART and DATEENDED and they're not next to each other! I can't understand the logic of this (I can understand why RPs might be separated out but not variables)

And in relation to above - if a variable has a 9 or less character name I can edit it add a single letter to its name and you can't!

Not the end of the world but daily annoyances that don't seem hard to fix.

Cheers
Jim

[atostaine]

Sometimes in RDMLX I don't see show variable contents. I've never been able to figure out why.

I agree with all of these points.

[dannyoorburg]

Hi Art,

I think there was a bug that got resolved in EPC142040 where that option was missing for Web Pages/Views/Dialogs and Server Modules.
Maybe that's what you're referring to.

That EPC also introduced the possibility to see the current value of variables in the hint.

Cheers,
Danny

[soa]

Danny

I certainly have a memory of seeing these issues resolved in an EPC but I have EPC142040 installed and these issues are still there.

[LANSAGuru]

I can confirm, with EPC142040 if you have either of

a) Long Named defined fields
b) Long Named defined Classes (like a field you drag on a screen)
c) Method Routine variables

they show up as a regular single level field value in the debugger, although things like c will have an expansion arrow next to it while an instantiation of a class as a field will not...not clear on the difference exactly

Other interesting things to note, on fields you can right click and there is an option which says Show Variables which jumps to the field in the debugger. This DOES NOT exist for method routine variables.

Also, it doesn't show variables which are not in context...for instance a method routine variable is not shown if you are not inside the method routine. I assume this is to not clutter up the debugger too much.

1.

I can think of an enhancement here which I think might be useful as well, to piggy back on this.
What about a toggle to turn off/on the object based stuff and off/on the variable based stuff (simple fields, variables, parms)? Most of the time we are not interested in object properties so something to just show the true field stuff would make less stuff to troll through to find the variable you are looking for. Just a thought.

2.

A question. At one point there was an option to change variables at runtime in the debugger. Was that removed on purpose? If so, curious about the reasoning.

[dannyoorburg]

Hi,

The debugger variable window lists (in this order)

- the instance you're in.
- the routine variables of your current scope
- the fields this instance uses (fields are GLOBALLY scoped by definition)


Routine variables don't exists if they're not in scope, so I'm not sure what you mean by wanting to see them, unless you mean the ones that are alive in other routines on the call-stack, but you can get to those just by clicking on that call-stack entry.


As for the difference between fields and components (expandable or not in the debugger):

I know it's a bit confusing if you use a field as a component instance (by dragging it onto a page/form) and you see it twice in the debugger, once under the current (#COM_SELF) component, because it's an instance scoped Define_Com, but on top of that its also listed as a field.

But it is basically correct, this component also behaves like a field, you can use it for instance as a field in an FETCH/SELECT statement.


Changing variables at runtime has never been supported for code that runs in the browser. The communication line between the browser and the IDE is just much more limited than the communication between a windows/IBM i executable and the IDE. You've seen it on Forms I guess.

Hope this helps.


Cheers,
Danny

[LANSAGuru]

Danny,

I could have sworn you could change variables in web, but probably just bad memory and/or experimental tip build feature that was scrapped.

You did a nice explanation of the different things shown in the variables panel. So my idea was to toggle some of those on and off at will so I don't have so much stuff to look at. I get the idea that it is a correct implementation of underlying detail.

The toggle could be a checkbox for each of these "things."

Simple fields (define #field #myfield *char 10)
component fields (define_com call(#repository field) name(#rename) or define_map)
Objects (these are things like controls on the screen which each might have 100 properties or so)

The important thing is, it is 99% of the time the simple fields and component fields (the variables) that programmers care about. Well I could be wrong about this, but that is true for me.

I might add one more thought, it would be nice to be able to look at what is INSIDE of working lists or inside of COLLECTIONS, but I understand that would conceptually be a lot of data flowing back and forth.

In my view the debugger is pretty good, the main problem is that there is a LOT of stuff to troll through sometimes to find what you need; nothing is sortable, nothing is filterable, nothing is searchable. Not the end of the world, but just a nice to have imo.

Thanks,
Paul

[jyoung]

+1 on visibility into lists and collections.

Joe

[adale]

+1 for enhancements to the Debug tool set.