quick question. So I've been working on saving my project, and I was doing some debugging 'cause things weren't functioning right. It seems fixed now, but I was wondering... After I promote the loaded game to a variable, I look at the return value, and at the end of the instance there's a 'C', underscore, then a number. The number is always incremented, so I'm wondering if I'm saving right. Should a save game instance always be the same, or does the number at the end increment each time you load from the slot?
ALSO, one other thing. How come after I cast to my save game object and get a variable, while I'm debugging it always says (Variable not in scope) when it IS getting the variable?
I assume your "loaded game" is a save game object, and I assume that you're testing in PIE. So you if you keep doing this then the game world is reconstructed over and over, so that the name of the loaded game object is being incremented. But if you close the editor then everything is restarted, also this incremented number (which is part of the object's name) is not saved in your save game unless you do it specifically. I mean you can get this name by dragging off from the object and call GetObjectName, and save it in save game object if you like.
For the second question, in many cases Blueprint debugging is not functioning well (like in a function library), so no bother with that "not in scope" thing, the Blueprint is running fine, just that you can't see the value. In this case you have to use PrintString to see what you want to know.
Whenever UE4 creates a UObject, it tries to give it the specified name. Every UObject has to have a unique name. If the name is taken, engine adds a number and increments until this name is unique.
You haven't specified the way you save/load your game. You can implement correct saving mechanic with creating a new game instance or using the same one.
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
Is there a field that exposes WHEN a work item is assigned to its current iteration?
Seems like a pretty basic thing one might like to know, but I can't seem to find it anywhere. Can someone point me in the right direction?
There is No field that exposes when a work item is assigned to its iteration.
If you want to see this value, you can go to the page of the work item.
And then click "History". What you need to find is the record of the latest iteration update.
Of course, you can also get this value through the REST API:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{id}/updates
But just like getting it by website, you need to spend some time looking for this value, and you can't apply it to queries.
If you really need a field that exposes when a work item is assigned to its iteration. You can create a new process that inherits from your current process and change the process of your project. Click this document for detailed steps.
And then, add a new field to show the latest updates of iteration. Click this document for detailed steps.
This way you can treat the iteration change time as a real field. However, the defect is that when you make changes to an iteration, you need to manually change the value of this field.
Where does the code that makes a PX Formula work exist? I at first assumed it was a SQL Trigger, but I can't seem to find it there. This is why I ask....
I've added a custom field to the SO, called usrSpeedyTotalExt2. I'm trying to get that to sum the SOLine.CuryLineAmt. I added attributes to the SOLine DAC to append the follwing:
[PXFormula(null, typeof(SumCalc<SOOrderExt.usrSpeedyTotalExt2>))]
This seemed to work, but know I'm fining that the value is consistently twice as high as it should be. I've got a second field that's doing the exact same thing.
What's increasingly odd is that I had the same problem with the field, and I thought I had done something wrong so I deleted the PXFormula, created a new field and then added the PX Formula to populate the new field. As such, there shouldn't be any code populating the old field, but strangely it's populated, so there must b e some business logic that's stuck and somehow still populating it.
Any thoughts on how I track this down?
I believe that I figured out the problem...I think that the code may have been imported and published on more than one company, then published from the proper company to multiple tenants.
My fix was to go to the live company, un-publish all, then go back to the company the customizations live in and publish to the appropriate tenants. It would appear that now I'm only getting the proper totals. IDK how that might have happened, but at least it appears to be fixed.
I'm in the middle of a RPA project at my work.
In the routine, a enterprise application is accessed many times and in some of those times it throws an error saying that "No element matched the query terms".
I guess there's some attribute in the window I'm trying to match that changes frequently, however every time I stop the process to check the issue, it doesn't happen...
I want to know if there's some way to grab the attributes identified of the window and store them in a log so I can compare between the attributes mapped and the ones intermittently observed in production.
I'm trying to read the contents of a "list view" using automation. The first time I navigate to it, I'm able to go from item to item, getting the correct text for each list item. However, when I display a different screen (which is apparently reusing this display object), the text on the screen is different, but automation gets the same text as the first set. From then on I can only get the text for the first view I looked at. It's like the text is being cached and I'm only able to look at the cached view. UISpy, however, seems to grab the right values every time, and if I use it while my automation is paused, I end up getting the right values.
In my automation, I use Find to grab the header, and walk the tree to the List View and get the text for each element. I thought if you used the Current property, you got the live data. Apparently I was mistaken. How do I either refresh the tree or get the REAL data?
Yes, the Current property on a certain AutomationElement will return its current, 'live', value. UIA will not cache anything automatically, you'll have to declare it yourself and explicitly access the Cached properties.
What's probably happening is that the new tree items you're seeing after selecting a different screen, are actually re-created (and that actually makes sense, UI-wise), not just updated. You could easily determine if this is the problem by selecting the first screen and writing down the tree items' RuntimeId property (you can see it in UI Spy). Then, select the second screen and check if the RuntimeId has changed. If it has, then it's just not the same object instance.
If this is the case, all you need to do is get the items again. It'll be easier to do this using AutomationElement.FindAll with a ClassName property condition.