Perspective is difficult to diagnose issues in

Ignition
,
1

I’m finding it quite difficult to diagnose issues in my Perspective projects.

For example, I have a View for embedding:
image

Where the Select button opens a popup:

image
image453×554 23.1 KB

Which has a flex repeater that uses this View:
image

I’m passing in a number of parameters including an availability table that lists the options in a dataset with a column that determines each option’s availability. Each View has at least 4-7 params that I pass in. There’s an issue somewhere along the line and my buttons in the popup aren’t working, but I’m struggling to work out what’s going wrong due to a number of reasons:

  1. I can’t open a popup from the Designer (this make diagnosing super fast, as you know exactly what’s being sent to the popup)
  2. script errors don’t show in a client - nothing happens
  3. View component property value ‘onchange’ scripts aren’t firing at startup, or are firing too early before the components are actually loaded… maybe, I don’t know
1 Like
2

I don’t have a good answer for you unfortunately, but I have had the problem with startup events not working properly as well. I agree that it seems as though the startup event scripts either don’t fire or fire too early to use the input parameters properly.
I have also had these issues:

  1. bindings that use input parameters initially are evaluated using the default value that is saved with the view and do not re-evaluate to the value that I expect based on what is passed into the input parameter.
  2. when attempting to clear the list of instances in the flex repeater and add new ones, the new instances sometimes have the values that the old ones had, even though I passed new values into each instance.

Sorry to hijack your thread with my own problems, but I thought these seemed related, and would love to hear from someone at IA if there is a solution that we are missing.

1 Like
3

@nminchin one thing that I have done as a hacky work around for the events not firing is to send a message (from some component such as a button) that refreshes all of the bindings or calls the scripts that you wanted to call on startup. It sucks to have to click on the button to get your stuff to load, but it was the best I could do to get my stuff working. In my specific case, I had the flex repeater load its instances behind the scenes while its visibility property was set to false, then I put a fake ‘load’ button onto the page that made the flex repeater visible and refreshed all of the bindings. Once again annoying to have to click the extra button, but it pretty much guaranteed that my components would be fully loaded and ready to refresh their bindings.

4

The lack of popups in the designer indeed does make debugging difficult. I somewhat mitigated this by using system.perspective.print() in a lot of places where I need to do debugging (or just use a logger) and combined that with a wrapper function to open my popups. This way in my wrapper function I can do logging/printing of the popup and params, so I at least know things were called.

5

I just happened across this old thread, but thought I’d add a suggestion. To overcome the fact that exceptions aren’t shown in the client, I put a try/except block around the code in question and print the exception, like this:

try:
    # do some stuff that might cause an exception
except:
    import traceback
    system.perspective.print(traceback.format_exc())

This gives me a nice printout in the browser console of the exception message and line number where the exception occurred.

6

This is basically what I use on all scripts in Perspective as well, otherwise you just get nothing :confused: I wish it did this automatically though

7

Agreed.

8

I guess I should make a library function to call and a popup to show it to the user :thinking:

9

This might be useful for you (all credit to @ryanjmclaughlin)

2 Likes
10

I would guess that the rationale there is that you don't want to 'leak' implementation details to users all the time; with Perspective's default of unauthenticated access, you could theoretically push something you don't want to an end user via an error message.

1 Like
11

That makes sense. Perhaps a “debug” project property could be added that would enable this behavior. We could disable this flag before publishing a project to production.

12

Yeah, there’s interesting ideas there.
To minimize your typing, you could have a context manager in a project library:

with utils.log_exceptions():
    pass

Context managers get access to any exception from the containing block on __exit__().

1 Like