Audio Recording Semantics Issues - xcode

So I am not very good with computers and have to create my first app for a project. It's going fine so far - essentially I am trying to create an app that records and saves data. Right now I'm still getting the record part down, since Xcode is having periodic issues. I am using this link for setting up the code:
http://www.techotopia.com/index.php/Recording_Audio_on_iOS_7_with_AVAudioRecorder
Unfortunately, I am running into 2 types of semantic errors, two red, two yellow. They are all in RecordModelController.m - the first is like this:
return [self.pageData indexOfObject:viewController.dataObject];
Xcode claims that Property 'dataObject' isn't found in any object or forward class in 'RecordDataViewController'. That's actually my two red errors, they just sound very similar so I paraphrased them into one. The yellow error, however, repeats itself twice on the same line of code, which is:
return [self viewControllerAtIndex:index storyboard:viewController. storyboard];
The yellow issues on these lines of code (again, repeated twice) is "Incompatible pointer types returning 'RecordDataViewController *' from a function with result type 'UIViewController *'" - I genuinely tried to look in RecordDataViewController.h and couldn't make sense of this. Like I said, bad with computers, not sure why I'm having this issue, and I know that it's probably something basic.
If anyone would be willing to help me out with how to deal with issues like this, that would be great. Thanks, and sorry for my incompetence.


The red are called errors. The yellow are called warnings. I'm going to suggest you look at a few beginning Xcode/iOS programming tutorials so you understand the basic concepts of how view controllers, arrays, etc. work in objective-c. The best place to start for someone completely new as yourself is here: http://www.raywenderlich.com/tutorials
Hope this helps!

Related

Cypress Assertions contradictions?

So i think this is one area that I run into issues with, and despite Cypress's amazing documentation assertions sort of feel lacking (but maybe thats because they use Chai assertions and I should be looking there? but even then i've run into confusion).
Anyways, it seems like when I am asserting on some items within cypress I return into conflicting results and I can't seem to pinpoint any reason why.
A few examples specifically:
Why does should(‘contain’,'{Some Text}) search child elements but should(‘have.text/value’,{Some Text}) does not? Or at least thats how it appears? I can't find any documentation that states this
In the example above I noticed this when having a cy.get on an angular dropdown toggle with a <span> within it (that contains the text).
Another oddity is have.text vs have.value. I've noticed sometimes works when the other doesn't. For example input fields only have.value works but not contains or have.text. Is there any reason for this?
I guess im trying to figure out if there is some cheat sheet/guide to when to use each one because it's mostly been trial and error for me (But i'd like to know "why" one works and the other doesn't).
Thanks!

Intermec Printer Language - Tabulation Problem

I'm an ABAP programmer and I was asked to make a minor modification to an IPL label.
Easily done, but now I was tasked to fix a long running error within said label.
I know nothing about IPL and the lack of a online viewer makes everything worse...
The problem is that "tabulation" right in the middle of a text (I underlined it in blue on the Label's pic).
I checked the code and there's nothing there that should make that tabulation appear.
I spent a whole month reading manuals and trying to fix it, but nothing changes...
Here's the code and the resulting label:
<STX>R<ETX>
<STX><ESC>C<SI>W791<SI>h<ETX>
<STX><ESC>P<ETX>
<STX>F*<ETX>
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,300052947-FANDANGOS PRESUNTO 140GX14 LD<ETX>
<STX>H2;f3;o130,52;c33;b0;h1;w1;d3,Val:<ETX>
<STX>H3;f3;o130,204;c34;b0;h1;w1;d3,QTD.Unidade:<ETX>
<STX>H4;f3;o90,33;c34;b0;h0;w1;d3,16/08/21<ETX>
<STX>H5;f3;o90,302;c34;b0;h1;w1;d3,14<ETX>
<STX>B6;f3;o375,44;c2,0;w6;h102;r0;d3,17892840816329<ETX>
<STX>H7;f3;o275,44;c26;b0;h17;w17;d3,17892840816329<ETX>
<STX>H8;f3;o130,490;c34;b0;h0;w1;d3,Lote:<ETX>
<STX>B9;f3;o090,600;c2,0;w2;h45;r0;d3,0005218177<ETX>
<STX>H10;f3;o130,600;c34;b0;h0;w1;d3,0005218177<ETX>
<STX>D0<ETX>
<STX>R<ETX>
<STX><SI>l13<ETX>
<STX><ESC>E*,1<CAN><ETX>
<STX><RS>1000<US>1<ETB><ETX>
Label
Can you guys help me, please??
Edit: Just to make it clear, I did that blue line on that image to show what's the problem.
Here are some tests I did by changing the data:
Test1
Test2
The error always appear at the same point in the label, as long as there's a space in that text.

Have you looked at the raw data of the output? Is it POSSIBLE that what looks like a space is actually some special character that is making IPL choke blue? Because it is literally the 1 character between the "O" and "1". For grins, you might also try to change the character in the data to a "-" just for purposes of confirming data context. It might even just be a TAB character.
I have done IPL years ago and have actually gone to the point of defining a pre-defined label template and generating output that says to use template X (whatever # I created as),and pass the data along that fills into the respective fields.
A final option I would throw in is this. Take the sample output you have and just force sample data into each of the output areas. So, instead of your literal data, put fake data in similar context just to see if it is data specific or other. Such as
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,300052947-FANDANGOS PRESUNTO 140GX14 LD<ETX>
becomes
<STX>H1;f3;o220,52;c34;b0;h2;w1;d3,123456789-TESTING-SAMPLEDATA-123XY12-AB<ETX>
Notice same context of data, but no spaces and using dash "-" just for testing. Is there something special about the actual data. This is a good way I have done historically for similar strangeness early on doing IPL labels.

User decided to not spend anymore time on this issue, so now I'm unable to further test the label.
Unfortunately this problem will go unsolved for now. Hope I get another chance to fix this and learn more about IPL.
Thanks you so much for your answers!

When cola.js fails, what's a fast way to find out what went wrong?

When cola.js fails, how do you find out what went wrong?
I don't have a minimal reproducible example, because that will likely take hours of debugging to make, and if I had it, then it wouldn't be an example of what I'm asking about. I'm hoping to hear of a way to quickly find out what's gone wrong. Presumably it's some bad data in my graph. But how can I tell what the bad data is?
The screenshot below illustrates a typical situation where something has gone wrong. Various NaNs are reported, there are a bunch of Uncaught TypeErrors, and an Assertion fails. There are a whole lot of local variables, all named with a single letter. Clicking and looking at them shows that a NaN got into a coordinate somewhere, as suggested by the previous error messages. It looks like sometime earlier, something got a null when it needed some sort of list-like data structure. How can I quickly find out what was the bad data that got into the graph?
I'm using cola.v3.min.js.
Details
I'm looking for a general approach to finding this kind of error, but here's the specific data that produced the errors in this example. Each line is the argument passed to cy.add() (as suggested by Stepan T.—and printing out everything passed to cy.add() might turn out to be the first step of the answer!).
{"group":"nodes","data":{"id":1,"label":"Workspace","parent":[]},"position":{"x":45,"y":0}}
{"group":"nodes","data":{"id":2,"label":"Target(121)","parent":[1]},"position":{"x":5,"y":0}}
{"group":"nodes","data":{"id":3,"label":"WantFullySourced","parent":[]},"position":{"x":50,"y":0}}
{"group":"nodes","data":{"id":4,"label":"Brick(120)","parent":[1]},"position":{"x":10,"y":0}}
{"group":"nodes","data":{"id":5,"label":"Avail","parent":[]},"position":{"x":55,"y":0}}
{"group":"nodes","data":{"id":6,"label":"Brick(1)","parent":[1]},"position":{"x":15,"y":0}}
{"group":"nodes","data":{"id":7,"label":"Avail","parent":[]},"position":{"x":60,"y":0}}
{"group":"nodes","data":{"id":8,"label":"Brick(2)","parent":[1]},"position":{"x":20,"y":0}}
{"group":"nodes","data":{"id":9,"label":"Avail","parent":[]},"position":{"x":65,"y":0}}
{"group":"nodes","data":{"id":10,"label":"Brick(3)","parent":[1]},"position":{"x":25,"y":0}}
{"group":"nodes","data":{"id":11,"label":"Avail","parent":[]},"position":{"x":70,"y":0}}
{"group":"nodes","data":{"id":12,"label":"Brick(4)","parent":[1]},"position":{"x":30,"y":0}}
{"group":"nodes","data":{"id":13,"label":"Avail","parent":[]},"position":{"x":75,"y":0}}
{"group":"nodes","data":{"id":14,"label":"Brick(5)","parent":[1]},"position":{"x":35,"y":0}}
{"group":"nodes","data":{"id":15,"label":"Avail","parent":[]},"position":{"x":80,"y":0}}
{"group":"nodes","data":{"id":16,"label":"NumericalRelationScout","parent":[1]},"position":{"x":40,"y":0}}
{"group":"nodes","data":{"id":17,"label":"OperandView","parent":[1]},"position":{"x":0,"y":0}}
{"group":"edges","data":{"id":"2.member_of.1.members","source":2,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"4.member_of.1.members","source":4,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"6.member_of.1.members","source":6,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"8.member_of.1.members","source":8,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"10.member_of.1.members","source":10,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"12.member_of.1.members","source":12,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"14.member_of.1.members","source":14,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"16.member_of.1.members","source":16,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"17.member_of.1.members","source":17,"source_port_label":"member_of","target":1,"target_port_label":"members","weight":0.5}}
{"group":"edges","data":{"id":"3.taggees.2.tags","source":3,"source_port_label":"taggees","target":2,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"2.support_from.3.support_to","source":2,"source_port_label":"support_from","target":3,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"3.support_from.2.support_to","source":3,"source_port_label":"support_from","target":2,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"5.taggees.4.tags","source":5,"source_port_label":"taggees","target":4,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"4.support_from.5.support_to","source":4,"source_port_label":"support_from","target":5,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"7.taggees.6.tags","source":7,"source_port_label":"taggees","target":6,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"6.support_from.7.support_to","source":6,"source_port_label":"support_from","target":7,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"9.taggees.8.tags","source":9,"source_port_label":"taggees","target":8,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"8.support_from.9.support_to","source":8,"source_port_label":"support_from","target":9,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"11.taggees.10.tags","source":11,"source_port_label":"taggees","target":10,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"10.support_from.11.support_to","source":10,"source_port_label":"support_from","target":11,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"13.taggees.12.tags","source":13,"source_port_label":"taggees","target":12,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"12.support_from.13.support_to","source":12,"source_port_label":"support_from","target":13,"target_port_label":"support_to","weight":2}}
{"group":"edges","data":{"id":"15.taggees.14.tags","source":15,"source_port_label":"taggees","target":14,"target_port_label":"tags","weight":0.5}}
{"group":"edges","data":{"id":"14.support_from.15.support_to","source":14,"source_port_label":"support_from","target":15,"target_port_label":"support_to","weight":2}}
The object passed to cy.layout() had a circular structure, so JSON.stringify() wouldn't print it. Adding the getCircularReplacer() function recommended here seemed to crash the browser. But manually removing elements from the layout object exposed the error: in a relative alignment constraint (documented under API here), I had an offset of '0' where I needed a 0, i.e. a string where a number was needed.
OK, happily that problem is now fixed. That still leaves the original question: is there a faster way to find errors like that? (The static-typing advocates are surely cackling by now.)

Using of Sitecore's XPath builder to test queries

i'm getting started with sitecore and i just discovered this tool sitecore offers to test our queries:
My problem is i just can't make it return results and i do know this query works perfectly cause i've been using it on my project right now.
There is probably a problem of syntax somwhere i don't know.
Thank you for helping me to put some light on this !

It's a bit difficult to tell due to how bits of that are redacted (there might be other syntax errors hiding under the boxes), but there's one obvious issue there, I think: You don't need the "query:" bit on the beginning of what you've typed.
In general, if the API or web form your filling in can only take a query expression you can leave the "query:" bit off. But if you're putting text into somewhere that might take a query or might take something else then "query:" is needed to tell Sitecore what it's looking at.

NOOB Problems with getting results from code (more specificly with NSComboBox)

I know that this is probably a simple question but here is what I'm racking my brain to figure this out:
I know that this:
- (id)comboBox:(NSComboBox *)aComboBox objectValueForItemAtIndex:(NSInteger)index {
return [midiModelContents objectAtIndex:index];
}
will return the item at the index provided. My question is, what code do I need to use to call this routine?
I've tried something like this:
NSString *curData =(comboBox: midiModel objectValueForItemAtIndex:0);
but I get a "error: 'comboBox' undeclared"
Can anyone help me with the concept that I'm messing up?

First, you might want to read the Objective-C Programming Language to learn the correct syntax for sending messages to objects, including yourself.
You get a nonsense error message because you have written (what is in Objective-C) nonsense code. A valid Objective-C message expression would compile and run successfully, but I don't think it would do what you're expecting it to.
You see (and this is the second thing), comboBox:objectValueForItemAtIndex: is not ordinarily a message you send to yourself. The combo box sends that message to you when you are its data source. Data sources are a variation on the delegate pattern that is among the things described in detail in the Cocoa Fundamentals Guide.
(You can send the message to yourself, and it may even make sense to do this if you deliberately want to go through the same object-value-retrieval path the combo box does, but this is not what you need to do to make a combo box work.)
Both the Language document and the Cocoa Fundamentals document are essential reading for every Cocoa programmer, along with the Memory Management Guide for Cocoa. You should read all three documents from start to finish.
The solution to your immediate problem is for the object that responds to comboBox:objectValueForItemAtIndex: to be the data source of the combo box. You will probably hook this up in IB, in the same nib where you created the combo box.
If none of that makes any sense, then all I can suggest to you is, again, to read those documents. They will explain everything.
If you really did simply mean to ask yourself for the object value the same way the combo box does (i.e., you have the combo box working already and intend to get the object value the same way for some other purpose), then you still need to read the Objective-C Programming Language document to learn the correct syntax to send yourself that message.

Resources