Graphics

Starting in version 11.0, all config files and logs for XPression have been moved to C:/Program Data/Ross Video/XPression*

This was done to support current and future industry security standards. 

Access Violations are either bugs, or a side effect of operating a feature in a totally unintended way. It is not unusual for them to generate each time the issue occurs, or only the first time the issue occurs. 

Ultimately access violations issue like this are generally only resolvable if they are reported and and we can figure out how to reproduce them consistently.  If we have the Project file we could identify if something unsupported is being done. 

If you just want some ideas thrown out.....are you using word wrap in your crawl? Word wrap can be quiet hard on the crawl system inside of XPression. 

Ah, that explains it. Thanks Garner.

That's always been the difficult part; I can share the project files and everything, but so many of the errors like this seem related to when live data is running through the project, and that makes it very difficult to both recreate myself (since everything is very time sensitive) and even further to have you guys recreate without access to or understanding of the data stream.

Word Wrap...no. I have no doubts I'm not going about the crawls we use in the best way. Ideally, I'd get the full crawl text itself over a data feed and feed it right into a text object, but not really something I have available. I use a lot of Visual Logic to construct the two strings that will be the crawl, so they're constructed in real time, and in the case of the official, goes from being an empty string to a quite long one.

My thoughts have always been that the transition of a string one size to a longer string might be throwing off the way the crawl group determines when to go to the next iteration, but I also have so many instances of this working, I've never found anything definitive. 

Starting in version 11.0, all config files and logs for XPression have been moved to C:/Program Data/Ross Video/XPression*

This was done to support current and future industry security standards. 

Access Violations are either bugs, or a side effect of operating a feature in a totally unintended way. It is not unusual for them to generate each time the issue occurs, or only the first time the issue occurs. 

Ultimately access violations issue like this are generally only resolvable if they are reported and and we can figure out how to reproduce them consistently.  If we have the Project file we could identify if something unsupported is being done. 

If you just want some ideas thrown out.....are you using word wrap in your crawl? Word wrap can be quiet hard on the crawl system inside of XPression. 

You might want to try building your crawl with 3 or more child scenes. XPression does crawls by lining up all the child scenes horizontally in a row and the width of each child scene is automatically set to whatever width is required to show all the bounding boxes in the child scene. For example, if Datalinq sets text in a child scene, and the text is 2000 pixels wide, the child scene will be 2000 pixels in width. 

So if your word wrap/project/script/API/datalinq/etc...is changing the width of the child scene that is next being crawled horizontally across the parent scene, you can cause XPression to hang up/crash/AV - because its trying to set the width of the child scene at the same time its trying to render it across the parent.  So ideally you want to make sure you are only modifying child scenes that are not next up, or currently being crawled.

This is a bad explanation of this, but hopefully gives a rough idea of what might be happening. 

Ah, that explains it. Thanks Garner.

That's always been the difficult part; I can share the project files and everything, but so many of the errors like this seem related to when live data is running through the project, and that makes it very difficult to both recreate myself (since everything is very time sensitive) and even further to have you guys recreate without access to or understanding of the data stream.

Word Wrap...no. I have no doubts I'm not going about the crawls we use in the best way. Ideally, I'd get the full crawl text itself over a data feed and feed it right into a text object, but not really something I have available. I use a lot of Visual Logic to construct the two strings that will be the crawl, so they're constructed in real time, and in the case of the official, goes from being an empty string to a quite long one.

My thoughts have always been that the transition of a string one size to a longer string might be throwing off the way the crawl group determines when to go to the next iteration, but I also have so many instances of this working, I've never found anything definitive. 

Starting in version 11.0, all config files and logs for XPression have been moved to C:/Program Data/Ross Video/XPression*

This was done to support current and future industry security standards. 

Access Violations are either bugs, or a side effect of operating a feature in a totally unintended way. It is not unusual for them to generate each time the issue occurs, or only the first time the issue occurs. 

Ultimately access violations issue like this are generally only resolvable if they are reported and and we can figure out how to reproduce them consistently.  If we have the Project file we could identify if something unsupported is being done. 

If you just want some ideas thrown out.....are you using word wrap in your crawl? Word wrap can be quiet hard on the crawl system inside of XPression. 

Yep, that makes sense.

That could very well be the problem; maybe the randomness of the breaks can just be bad timing of when the data comes in. Most of the time it's okay, but sometimes it just isn't. The issue I think I'm having is I really only have 1 child scene, that displays the one string, but the content of the string changes. So, for the looping, I have that scene duplicated. I can do it a third time for each crawl; but I feel like that wouldn't fix the problem.

Maybe turning off Live Update could help? But then I think I would have problems with how the parent scene reacts being out of sync with the child scenes.

You might want to try building your crawl with 3 or more child scenes. XPression does crawls by lining up all the child scenes horizontally in a row and the width of each child scene is automatically set to whatever width is required to show all the bounding boxes in the child scene. For example, if Datalinq sets text in a child scene, and the text is 2000 pixels wide, the child scene will be 2000 pixels in width. 

So if your word wrap/project/script/API/datalinq/etc...is changing the width of the child scene that is next being crawled horizontally across the parent scene, you can cause XPression to hang up/crash/AV - because its trying to set the width of the child scene at the same time its trying to render it across the parent.  So ideally you want to make sure you are only modifying child scenes that are not next up, or currently being crawled.

This is a bad explanation of this, but hopefully gives a rough idea of what might be happening. 

Ah, that explains it. Thanks Garner.

That's always been the difficult part; I can share the project files and everything, but so many of the errors like this seem related to when live data is running through the project, and that makes it very difficult to both recreate myself (since everything is very time sensitive) and even further to have you guys recreate without access to or understanding of the data stream.

Word Wrap...no. I have no doubts I'm not going about the crawls we use in the best way. Ideally, I'd get the full crawl text itself over a data feed and feed it right into a text object, but not really something I have available. I use a lot of Visual Logic to construct the two strings that will be the crawl, so they're constructed in real time, and in the case of the official, goes from being an empty string to a quite long one.

My thoughts have always been that the transition of a string one size to a longer string might be throwing off the way the crawl group determines when to go to the next iteration, but I also have so many instances of this working, I've never found anything definitive. 

Starting in version 11.0, all config files and logs for XPression have been moved to C:/Program Data/Ross Video/XPression*

This was done to support current and future industry security standards. 

Access Violations are either bugs, or a side effect of operating a feature in a totally unintended way. It is not unusual for them to generate each time the issue occurs, or only the first time the issue occurs. 

Ultimately access violations issue like this are generally only resolvable if they are reported and and we can figure out how to reproduce them consistently.  If we have the Project file we could identify if something unsupported is being done. 

If you just want some ideas thrown out.....are you using word wrap in your crawl? Word wrap can be quiet hard on the crawl system inside of XPression.