I googled trying to find the answer, but failed.
It's actually a quick question, and i just don't have enough memory-management and objective-understanding to solve it properly by myself.
If someone ever user WEPopover library(great tool, thanks to developers https://github.com/werner77/WEPopover), they remember that there is a warning in WEPopoverController.m:
//First force a load view for the contentViewController so the popoverContentSize is properly initialized
contentViewController.view;
and the warning as follows:
Property access result unused - getters should not be used for side effects
I'm not pretty sure what are they trying to achieve, but i truly believe it's not a propoer way to initialize things, but i am not sure if i should use any methods, because i don't want to disturb the functionality.
Any advices and hints will be hihgly appreciated!
I just solved it, I had the same issue! :)
just replace contentViewController.view; with [contentViewController view];
That's all. You might solved it, as you've asked it a longtime before! But it would be helpful to other if they will find the same issue:)
Related
I am really struck and trying to find a way to remove all unused methods in Angular project
Basically I am restructuring the whole project and changing logic to accommodate the new structure. Above is the example screenshot.
Upon hitting Alt + Enter > I did not find anything to remove all unused methods at a go.
Tried the code -> code cleanup. But no luck
Kindly help
There is currently no way to do this (likely because such quick fix would be rather unsafe, because not all methods that are not called explicitly in your code are actually unused - like different lifecycle hooks). Anyway, if you miss it, please feel free to file a feature request to youtrack, https://youtrack.jetbrains.com/issues/WEB
EDIT: this is now solved and i no longer need help. see solution below. thank you
I am getting a weird error when trying the new decorate syntax with computed variables - any idea why it might sometimes invalidate the store? I'm pretty sure the computed is causing this as it works when I remove it.
sandbox here: https://codesandbox.io/s/jnmz0v2189
and screenshot here:
i should use decorate on the class, not the instance.
https://twitter.com/askerovlab/status/974752575676436481
more info here.
I would like to gain a full understanding of how events work in Dojo. I am actually interested in the way Dojo 2.0 works -- I am using 1.8 now, but I am only really interested in using/documenting features that will not be deprecated for 2.0.
Now... in _WidgetBase.js I read:
on: function(/*String|Function*/ type, /*Function*/ func){
// For backwards compatibility, if there's an onType() method in the widget then connect to that.
// Remove in 2.0.
This basically means that in the near future a widget's on will basically do:
on: function(/*String|Function*/ type, /*Function*/ func){
// Otherwise, just listen for the event on this.domNode.
return this.own(on(this.domNode, type, func))[0];
Which is fine. Now... in the release note for 1.8, I see:
"Widget events, including attribute changes, are emitted as events on the DOM tree"
The release note point to this: http://livedocs.dojotoolkit.org/quickstart/events#widget-events-published-to-the-dom Which "sort of" explain things, although the document seems to be outdated (it still talks about aspect for "plain object").
So, my question: is there a spot/bunch of pages/tickets that would describe the current updated way in which the whole events thing works?
My current understanding (for Dojo 2.0):
on: 100% delegated to on.js
emit: when you run randomWidget.on('something', function(){}):
-if randomWidget has 'onsomething', it will simply run that; <--- will this go away with 2.0?
-Otherwise, it will delegate to on()
So, it's all about understanding dojo/on. That's when I get confused: reading the source code, on.js seems to delegate functionality to the widget itself (which... I just wrote above, will simply delegate to dojo/on from 2.0...?!?). Unless the bit that delegates to the object is destined to disappear...?
Also, I am used to writing widgets with templates, and then add items where I do data-dojo-attach-event="onclick:_click" where I make sure a function is called when somebody clicks on it. With the new on() system, will this change? (I mean, is all events propagates to DOM, is the opposite also true?)
So, can somebody shed some light on this? I feel a little uneasy at the moment, adding events and doing things, because I am not 100% sure of what is going on.
Thank you!
Gosh that was a while ago...
Since then, I wrote this:
https://github.com/mercmobily/writeups/blob/master/dojo/widgets_containers_on.md
Which explains pretty much the whole lot!
Merc.
We've got an application that on rare occasions crashes with the error:
Missing proxy for identifier IBFilesOwner
We understand it to be implying that it can't find File's Owner for one of our nibs (xibs) but we've been through and confirmed they all have valid ones set.
There's practically zero on Google, can anyone offer any suggestions?
Thanks.
Hey I had the same problem and it turned out that I was doing some threading and I was executing code that should be on the main thread on another thread.
I don't know what you're doing in your app, but hopefully that might give you a clue.
If you share some code we can try and figure out what's going on.
Can anyone please explain the difference between plexus-classworlds and (plain) classworlds?
These two are confusing and can't see the difference. Plexus classworlds contains almost no description. Apparently, a maven-based Java project uses both, I don't understand why.
Is it possible to replace classworlds with plexus-classworlds without much hassle?
I'm gonna answer that, even though the question is so old...
classworlds was migrated to plexus-classworlds, but the documentation on the site doesn't seem to keep up with that... the best docs I've seen was on classworlds 1.1-SNAPSHOT, although the current is plexus-classworlds 2.4.1-SNAPSHOT, and there is hardly any doc there.
if you look at plexus-classworlds, you can also see the original org.codehaus.classworlds package, with class comments like this:
A compatibility wrapper for org.codehaus.plexus.classworlds.launcher.Launcher provided for legacy code
which means that they thought about migration, but of course nothing replaces a thorough test.