Using polymer-gestures to test custom element - unit-testing

Why is this test causing the following failure and error?
expected 'NO. ONE' to equal 'ITEM TWO'
<unknown> at /swiper-slider/test/basic-test.html:59
Object.Fake.downAt at /polymer-gestures/test/js/fake.js:98
Object.Fake.downOnNode at /polymer-gestures/test/js/fake.js:89
Context.<anonymous> at /swiper-slider/test/basic-test.html:56
polymer-gestures/test/js/fake.js is failing to find the target in this method, called from this method but I can't narrow down the exact culprit.
My hunch is that it has something to do with the div.swiper-button-next element being appended as a child on the fly and use of document.querySelector('swiper-slider /deep/ div.swiper-button-next') in the test.

I have a hunch that one of a few things is happening.
the div.swiper-button-next isn't in the DOM by the time you make the call. Either work a callback into your system to fire when everything is done (then check the value inside that callback), or (just to test if this is actually the problem) put a manual setTimeout to delay the query selector and assertion for a bit.
Polymer's targetAt function uses elementFromPoint() internally. Double check to make sure you don't have any overlays (core-overlay tends to crap all over my window sometimes...) and that the element you really want to tap is actually the element being found. Don't be afraid to put some debugging/console.log statements into the actual polymer source code to see what it is finding there.
I haven't spent too much time looking over the test, but your slideEls[1] could possibly have changed since you queried for it. querySelectorAll returns a "non-live" nodelist, so changes to the DOM don't update your selection.

Related

WTL CListViewCtrl getSelectedItem is causing an Assertion fail for me

This is my code in order to get the name of the item which has been selected in my CListViewCtrl:
LVITEM item = { LVIF_PARAM };
CString itemText;
clistViewCtrl.GetSelectedItem(&item);
clistViewCtrl.GetItemText(item.iItem, item.iSubItem, itemText);
Note that this code is working. I recently did another project, where I grabbed the name in exactly this way, however, I had no problems there with any assertion fails.
When I execute this with my current project, I always get a debug assertion:
"File: ... atlctrls.h"
Line: 3242
Expression: (GetStyle() & 0x0004) != 0
Even though the expression already states it pretty much, here is the line causing the failure:
ATLASSERT((GetStyle() & LVS_SINGLESEL) != 0);
I have barely any idea what the problem is. As I said, the exact same code worked on my other project, and I just went through both, trying to find any differences which could cause this behaviour, but nothing caught my eye.
Honestly, I don't even know if this is related to my code at all, considering the two compared elements seem to be predefined.
My first guess would have been that this part is being called before the items are created, but all items in the listview are created at the point I try to call this code passage.
Can anyone point me to a solution?
Your control is not created with style flag LVS_SINGLESEL. So calling GetSelectedItem is causing an assert. In case of multi selection use GetFirstSelectedItem and GetNextSelectedItem instead of GetSelectedItem. For single selection you can continue useing GetSelectedItem, but you have to add LVS_SINGLESEL style flag to your control.

Ember ember-views.render-double-modify

Using Ember.2.1.0-beta4
I am getting the "ember-views.render-double-modify" in a function triggered by the "didReceiveAttrs" of a subcomponent.
I tracked down the statement this.set('_columns', columns) that triggers the error. However, AFAIK this is the first time the attribute is modified.
To debug it, I created an observer for the modified attribute, and put a breakpoint there. However, the observer is only called once and the error is still there, so it looks like this is the first call.
How should I debug this -- is this an Ember bug, or are there other restrictions on setting attributes that aren't clear in the error? Note that the attribute is used in the component's template. Also the attribute is used in other computed attributes (e.g. _columns.#each.width and _columns.[]).
For posterity's sake, the answer in my case was: _columns is used in the template. Thus, for didReceiveAttrs of the subcomponent to be called, the previous value of _columns was already used.
The error message is a little misleading, but the idea, I think, is that once you start to render you can't change properties until you are done. If necessary, use Ember.run.scheduleOnce('afterRender', ...).

Playing with Ember.Object.reopen(), why I have those results?

I was trying to answer this question: emberjs: add routes after app initialize()
I started to play with Ember.Object.reopen(), to understand how it works, and perhaps finding a way of answering the previous question.
I feel a bit puzzled, and don't understand the behavior of this code:
jsfiddle: http://jsfiddle.net/Sly7/FpJwT/
<script type="text/x-handlebars">
<div>{{App.myObj.value}}</div>
<div>{{App.myObj2.value}}</div>
<div>{{App.myObj3.value}}</div>
</script>
App = Em.Application.create({});
App.MyObject = Em.Object.extend({value: 'initial'});
App.set('myObj', App.MyObject.create());
Em.run.later(function(){
App.get('myObj').reopen({
value: "reopenOnInstance"
}); // the template is not updated, 'initial' is still diplayed, but
console.log(App.get('myObj').get('value')); // print 'reopenOnInstance'
App.MyObject.reopen({
value: "reopenOnClass"
});
App.set('myObj2',App.MyObject.create()); // the template is updated and
console.log(App.get('myObj2').get('value')); //print 'reopenOnClass'
App.myObj3 = App.MyObject.create(); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'reopenOnClass'
Em.run.later(function(){
App.get('myObj').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj').get('value')); // print 'setWithSetter'
App.get('myObj2').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj2').get('value')); // print 'setWithSetter'
App.myObj3.set('value', "setWithSetter"); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'setWithSetter'
}, 2000);
},2000);
If someone can explain what is going on, particularly why the templates are sometimes not updated, sometimes updated, and also what's the difference between calling reopen on a class, calling it and on a instance.
Not 100% sure, but I will try and answer you questions.
First lets look at "myObj3". The ember getter/setter methods trigger the updates in the templates (they fire internal events which cause every property/observer to know something happened). Just setting a value by hand does update the value but will not fire these events and hence nothing changes in the UI. Kind of like when you use a Mutable list you use pushObject to make sure the UI updates.
Now lets look at your "reopen". When you reopen on the class it works as you would expect and updates the base class. When you reopen an instance it is actually creating a mixin and shims it on top of the object. This means when you do a "get" ember iterates over the mixin & object for the value to return. It finds that mixin and gets the value before the object; you could actually replace the method with a "return 'foo '+this._super()" on the instance you will get 'foo initial' (think of your object has having layers like an onion). If you have a group of mixin on top of your object you will have a hard time finding the correct value if you set something directly (but "get" will work perfectly). This leads to the general rule that you should always use "set" instead of a direct reference.
Side note: You can call "getPath" instead of "get" and you can use the relative or absolute path. Such as App.getPath('myObj2.value') which will make the code a little easier to manage. Goes for "setPath" also.
Lastly: The last value prints because you did change the value (it is in there) but the trigger for ember to update the ui never fired because you never called set on "myObj3" object.
EDIT: In the lastest version of ember it looks like the reopen on an instance does do a merge-down on the object (if that key already exists). The mixin only will wrap if you are adding new content.

Google Geocoder Returning null From Reverse Lookup

I am trying to use the Google geocoder to do a reverse-geocoder lookup. I am running the exact same command on 8 values, and I am only having an error on two of them, which has me confused as one of the failing values is identical to one of the working values. (The 'working' values aren't really working- they still return a value of undefined from the 'formatted_address' field, but they aren't throwing errors). The command that I am running is as follows:
geocoder.geocode({latLng: new google.maps.LatLng(machineList[i].y, machineList[i].x)}, function(results, status) { address = results[0]; });
I am receiving a type error from Javascript, claiming that results is null. I'm not sure why this is happening. Any ideas?
Well, it turns out this was a timing issue. The geocode() command was taking longer to complete for certain locations than for others, which caused the value to show up as null. I ended up eliminating the problem by moving all the subsequent code into the callback function (I hadn't done this earlier because the whole thing is running inside of a loop, and I was having some difficulty getting it to pass in the iterator as a parameter). Now everything seems to be working well and the locations are showing up as they should.

Using Lua to define NPC behaviour in a C++ game engine

I'm working on a game engine in C++ using Lua for NPC behaviour. I ran into some problems during the design.
For everything that needs more than one frame for execution I wanted to use a linked list of processes (which are C++ classes). So this:
goto(point_a)
say("Oh dear, this lawn looks really scruffy!")
mowLawn()
would create a GotoProcess object, which would have a pointer to a SayProcess object, which would have a pointer to a MowLawnProcess object. These objects would be created instantly when the NPC is spawned, no further scripting needed.
The first of these objects will be updated each frame. When it's finished, it will be deleted and the next one will be used for updating.
I extended this model by a ParallelProcess which would contain multiple processes that are updated simultaneously.
I found some serious problems. Look at this example: I want a character to walk to point_a and then go berserk and just attack anybody who comes near. The script would look like that:
goto(point_a)
while true do
character = getNearestCharacterId()
attack(character)
end
That wouldn't work at all with my design. First of all, the character variable would be set at the beginning, when the character hasn't even started walking to point_a. Then, then script would continue adding AttackProcesses forever due to the while loop.
I could implement a WhileProcess for the loop and evaluate the script line by line. I doubt this would increase readability of the code though.
Is there another common approach I didn't think of to tackle this problem?
I think the approach you give loses a lot of the advantages of using a scripting language. It will break with conditionals as well as loops.
With coroutines all you really need to do is:
npc_behaviour = coroutine.create(
function()
goto(point_a)
coroutine.yield()
say("Oh dear, this lawn looks really scruffy!")
coroutine.yield()
mowLawn()
coroutine.yield()
end
)
goto, say and mowLawn return immediately but initiate the action in C++. Once C++ completes those actions it calls coroutine.resume(npc_behaviour)
To avoid all the yields you can hide them inside the goto etc. functions, or do what I do which is have a waitFor function like:
function waitFor(id)
while activeEvents[id] ~= nil do
coroutine.yield()
end
end
activeEvents is just a Lua table which keeps track of all the things which are currently in progress - so a goto will add an ID to the table when it starts, and remove it when it finishes, and then every time an action finishes, all coroutines are activated to check if the action they're waiting for is finished.
Have you looked at Finite State Machines ? If I were you I wouldn't use a linked list but a stack. I think the end result is the same.
stack:push(action:new(goto, character, point_a))
stack:push(action:new(say, character, "Oh dear, this lawn was stomped by a mammoth!"))
stack:push(action:new(mowLawn, character))
Executing the actions sequentially would give something like :
while stack.count > 0 do -- do all actions in the stack
action = stack:peek() -- gets the action on top of the stack
while action.over ~= true do -- continue action until it is done
action:execute() -- execute is what the action actually does
end
stack:pop() -- action over, remove it and proceed to next one
end
The goto and other functions would look like this :
function goto(action, character, point)
-- INSTANT MOVE YEAH
character.x = point.x
character.y = point.y
action.over = true -- set the overlying action to be over
end
function attack(action, character, target)
-- INSTANT DEATH WOOHOO
target.hp = 0
action.over = true -- attack is a punctual action
end
function berserk(action, character)
attack(action, character, getNearestCharacterId()) -- Call the underlying attack
action.over = false -- but don't set action as done !
end
So whenever you stack:push(action:new(berserk, character)) it will loop on attacking a different target every time.
I also made you a stack and action implementation in object lua here. Haven't tried it. May be bugged like hell. Good luck with your game !
I don't know the reasons behind you design, and there might be simpler / more idiomatic ways to it.
However, would writing a custom "loop" process that would somehow take a function as it's argument do the trick ?
goto(point_a)
your_loop(function ()
character = getNearestCharacterId()
attack(character)
end)
Since Lua has closures (see here in the manual), the function could be attached to your 'LoopProcess', and you call this same function at each frame. You would probably have to implement your LoopProcess so that that it's never removed from the process list ...
If you want your loop to be able to stop, it's a bit more complicated ; you would have to pass another function containing the test logic (and again, you LoopProcess would have to call this every frame, or something).
Hoping I understood your problem ...