AbilitySystemComp GetSet retrun null - unreal-engine5

I have been implementing GAS in a project of mine and something is bugging me to no end.
In this youtube video made by unreal, they use the function
AttributeSet = AbilitySystemComponent->GetSet<UGASAbilityDemoAttributeSet>();
Where according to the video and the doc, GetSet is supposed to return the set if it exists or creates it and then give the newly created set. However, when I use it, it always returns null and I can't find a difference in my implementation.
What is it that I am doing wrong?
Other Sources
In the docs, they also mention to do the same.
I also downloaded and look at the implementation for the new Lyra demo project where it's a lot more complex, but in the end, they, themself, do the same.
Note
I know I can just
MySet = CreateDefaultSubObject<UGASAbilityDemoAttributeSet>("My Set")
To create my set, but the fact that I'm unable to use it like they do bug me.

I had the same issue. I found out that you have to first set the "Default Starting Data" on you Ability System Component in the editor. After that the GetSet method returns an object.
screenshot

Related

How to differentiate if a TBO is called when importing new Document vs for any other operations

We are trying to add one additional feature to our method for TBO. The feature needs to be executed only when a new document for that object type is imported and should not be executed in any other case like checkin checkout or any changes in attributes.
However the new code is getting called everytime we make any changes to attribute to that document.
We have put that code in doSave() method.
I tried isNew method for distinguish between newly imported Document and other scenarios, however could not get success, may be missing the usage details of the method.
Can anyone suggest anything?
We are on Documentum version 7.2.
I always use isNew() method to check is object new or versioned, I don't remember having problems with it at any DFC version.
Only one thing that comes in mind is to make sure you don't use super.doSave() while inside the code since right after it method will return false.
But this is expected behaviour.
If you really need to do this - some calulations based on programatically preset data - make sure you use value saved within local variable throughout your code.
If you think you are experiencing bug with the method try with another DFC version or report a bug to the Support.

Working with reference lists in canned workflows

I am experimenting with canned workflows and need to know if it's possible to work with lists of domain objects in a reference variable, i.e. reference lists. Here is some code to illustrate the concept...
public void Run(Workflow workflow)
{
ReferenceVariable variable = workflow.InputReferenceVariables.First();
WorkflowRunner runner = new WorkflowRunner(workflow);
List<PointSet> pointSets = PetrelProject.Inputs.Selected.OfType<PointSet>().ToList();
runner.SetInputVariableBinding(variable, pointSets);
runner.Run();
}
This following picture shows the basic workflow.
"Local reference variable 1" is the input variable to which I am assigning the reference list. I know the example is hacky, but I tried to simplify everything as much as possible.
Anyways, it doesn't seem to work by binding a list, but it also doesn't throw any exceptions. Nothing happens at all when I run it. Anyone have any ideas?
Official response from Schlumberger is that reference lists are not yet supported. There is a work item in their system to provide a reference list API, but it is not yet target for a release.

Item is not added into the list (from code)

We have some strange problem here. We have feature event receiver, where we are creating custom fields -> content type -> list. After that, one default item is added. On my VM it was working just fine, but after moving into pre-prod environment, we got this strange behavior with no exception or error in logs.
First thing, item was created only sometimes, with no trace what happened. Mostly it was not created. I even experienced this: when I activated feature, I went to the list and so item there, but after refresh it was gone!
We tried to put there some Thread.Sleep() cycle (while debugging, item was in Items collection, but ItemsCount property of the list was always showing 0).
Now I am out of ideas what is wrong. It's not about execution time (maybe). Looks like, for some reason, SP is killing SPItem.Update before it is created for real and we don't know why. Any help is really welcome!
When you try to access sharepoint items from code and not have admin permissions to update/ delete them then set website website.AllowUnsafeUpdates = true; property
//Set AllowUnsafeUpdates = true to update the database / sharepoint list from code.
FormWeb.AllowUnsafeUpdates = true;
NewItem.Update();
FormWeb.AllowUnsafeUpdates = false;
you code should be like this to make changes in the list.. when you adding item to list.
Use Update statement in same manner when you accessing list and updating its data.
Check whether you updating the list correctly.. There may be some SharePoint security issue.
Reference Link:
http://blogs.msdn.com/b/infopath/archive/2010/04/01/add-items-to-a-sharepoint-list-using-managed-code.aspx.
You can check this [SPSecurity.RunWithElevatedPrivileges][1]
[1]: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx , link, link
you can check that what is going over there by adding your events in sharepoint..
Check this post and debug it..
http://developmentsolutionsjunction.blogspot.com/2011/06/adding-events-and-eventhandlers-in.html
so I was finally able to find out where the problem was. After deeper study and trying that and this I found out that there was a third party feature. It was adding event to each created list and was deleting everything what wasn't consistent with CT defined by company. This is weird and I don't really understand why somebody wants this. But ok, they pay, their rules.
So if you encounter such problem, try also this possibility.
However, I also leard few things during this, e.g. if you are working with SP instances from web scope, use web scoped features, not site ones, also, SP has a nasty habit to silent som exceptions. Also, if you e.g. take instance of SPWeb from event properties, it doesn't necessarily means it is already created. It takes some time, also, Update() itself is a thing that DB has to perform. Sometimes it's better to alsways check if you really have instance and if not, threadsleep for a while.
Have you used .Update() method in your code??

How to access an EKCalendar's `account` property

Take a look at the documentation for EKCalendar. It's pretty simple, it has five properties, only one of which is a string called title. Now if you have multiple calendars on your iPhone and you open iCal's Calendar settings, you can see that all calendars are nicely grouped by another string called account.
What I can't figure out, is how to do the same, because although you can see the account when you NSLog a EKCalendar instance, you can't access it:
EKCalendar <0x1851b0> {title = Work; type = CalDAV; account = some#addr.ess; allowsModify = YES; color = 0.690196 0.152941 0.682353 1.000000}
There is no account property, and trying to access the valueForKey:#"account" isn't working either, unsurprisingly.
So how do I get to that account property? Such a simple thing, driving me nuts! Help is much appreciated.
Update: since iOS 5.0, EKCalendar has a source property.
If you use class-dump on the iOS 4.3 (Simulator) SDK, you'll see that there's a read-only method -(id)accountName. However, since it's not in the headers, it's unfortunately private API and you can't use it if you want your App to be accepted in the App Store.
I recommend that you file an enhancement request with Apple requesting that this method be made public.
Though thinking about it: If you're really desperate, why not parse the output of -[EKCalendar description]? It's very very very bad style and it'll probably break in the future, but you might make it through the App Store review ;) In particular if you only use it for grouping and write your code extremely defensive so it doesn't break but simply doesn't group, should the output of the description method be formatted differently.
This information is not available in the 4.0 SDK. Have you looked at the developer previews of the forthcoming SDK to see if that might contain more information?
And on iOS6? It seems the private property [EKCalendar accountName] vanished. And [EKCalendar description] does not contain account anymore. :
EKCalendar <0x200f50e0> {title = test#gmail.com; type = Exchange; allowsModify = YES; color = #44A703;}
The [EKCalendar source] provides a EKSource object, that has a title but this is not the name I typed when I created the account but seems to be a more generic name, e.g. Exchange, Other, CalDAV.

Using /ApplicationPublicName does not change AppName() output

I know it's a long shot that there might be any uniPaaS developers on here, but here goes:
Today for the first time I've gone to duplicate a system we have in uniPaaS 1.5.
In the uniPaaS broker, I added the flag /ApplicationPublicName to change the
APPNAME that the application responds on.
However, the AppName() output that the application generates is still the
original name of the application, not what I specifying as the
ApplicationPublicName.
Our system relies heavily on AppName(). Is there any way to get AppName() to
return the same value as /ApplicationPublicName?
the AppName() function returns that application name as it was defined in settings, application.
If you want the appname to return something else, simply iniput that value to the Magic_Systems section of the ini file.
Better late than never to answer your own question I guess.
To work around this, we internally depreciated the use of the AppName() function, and instead replaced it with our own IntAppName(). Our new function does an INIGet('ApplicationPublicName') and returns that, as AppName() seems to always be fixed to the name of the application when it was compiled.
This was 4 years ago on 1.5 - perhaps v2.0 is different now, but we have continued to use our internal function without issue.