This bug is caused by a change from iOS 8 of Core Location framework. Unfortunately, apple didn’t aware us clearly about this change in it release documents. In iOS 8, old code of location doesn’t work, it fails silently so we hard to recognise it fail. Core Location in iOS 8 requires some more attributes, and some attribute of checking for location status has changed. You can see detail here: http://nevan.net/2014/09/core-location-manager-changes-in-ios-8/
The Project needs to be rebuilt as you made changes to a subreport and the report data is not current.
The Report data is corrupt some how and needs to be erased (look in your FILE location and delete the *.rdl.data file.)
Your parameter you are passing in is bad or in the wrong format. All Subreports having parameters NEED TO HAVE THEM PASSED IN, or they will not run and give an error the equivalent of 'object set to an instance of a null'.
We can filter today date using report's built-in field execution time:
=Format(Globals!ExecutionTime,"yyyy-MM-dd")
The Execution Time is formatted as yyyy-MM-dd to be compatible with the query.
Now we can add a parameter field, named "TodayFetchXML", and set it's default value to the expression above and use it to parameterize our FetchXML like this:
We can filter on other dates by adding/subtracting days:
// Parameter function for @YesterdayFetchXML
=Format(DateAdd("d",-1,Globals!ExecutionTime),"yyyy-MM-dd")
// Parameter function for @TomorrowFetchXML
=Format(DateAdd("d",1,Globals!ExecutionTime),"yyyy-MM-dd")
Combining with new FetchXML date operators: on-or-before and on-or-after, we can create more flexible query
Simply addenableprefiltering="1"attribute to entity node in FetchXML
For example:
It will create a parameter field for entity ID automatically in format CRM_
We can also set the name for the parameter field in FetchXML using prefilterparametername=""
If the report is uploaded to CRM solution without prefiltering enabled, we need to delete that report in the solution and upload prefiltering enabled report again.
So when ASP.NET Webform was so successful, why Microsoft thought of
creating ASP.NET MVC.The main problem with ASP.NET Webform is
performance, performance and performance. In web application there are
two aspects which define performance:
Response time: - How fast the server responds to request?.
Bandwidth consumption: - How much data is sent ?.
Response time issues
Let us try to understand why response time is slower when it comes to
ASP.NET Webforms. We did a small load testing experiment of Webform vs
Asp.Net MVC and we found Asp.Net MVC to be twice faster.
Let us try to understand why ASP.NET MVC was better in performance in
the above load test.Consider the below simple UI code and Code behind
for that UI.
Assume the ASPX code has the below simple text box.
In the code behind you have written some logic which manipulates the text box values and the back ground color.
When you run the above program below is the HTML output.
If you see the HTML output by doing view source it looks something as shown below.
Now stop reading for a moment, close your eyes and think. Try to get answers to the below questions:
Is this a efficient way of generating HTML?. Do we really need to
make those long server trips to get those simple HTML on the browser ?.
Can’t the developer write HTML straight forward, Is it so tough?
If you see for every request there is a conversion logic which runs
and converts the server controls to HTML output.This conversion get’s
worse and heavy when we have grids, tree view controls etc where the
HTML outputs are complicated HTML tables. Due to this unnecessary
conversion the response time is less.
Solution for this problem: “GET RID of CODE BEHIND”, fold your sleeves and work with pure HTML.
Bandwidth consumption
Viewstate has been a very dear and near friend of ASP.NET developers
for past 10 years because it automatically saves states between post
backs and reduces our development time. But this reduction in
development time comes at a huge cost, viewstate increases the page size
considerably. In this load test we found viewstate increases the page size twice as compared to Asp.Net MVC.
Below is the plot of the content length emitted from Webform and Asp.Net MVC.
The size increase is because of extra bytes generated from viewstate,
below is the snapshot of a viewstate. Lot of people can argue that
viewstate can be disabled but then we all know how developers are, if
there is option given they would definitely try that out.
Solution for this problem: “GET RID of SERVER CONTROLS”.
Note: The rest of the three points down below are browny issues
which have cropped up due to presence of code behind and server
controls. But the main thing is always performance.
HTML customization
Now because we are salves of the code behind and ASP.NET web server
controls, we have “NO IDEA” what kind of HTML can come out and how
efficient they are. For example see the below ASPX code, can you guess
what kind of HTML it will generate.
I am a panel
Will Label generate DIV tag or SPAN tag ?. If you run the above code
below are the respective generated HTML. Label generates a SPAN ,
Literal generates simple text , Panel generates DIV tag and so on.
I am label
I am a literal
I am a panel
So rather than generating HTML using server controls how about writing HTML directly and taking complete control of HTML.
So the solution for this problem is “DO NOT USE SERVER CONTROLS” and work with direct HTML.
The other great benefit of working directly with HTML is that your
web designers can work very closely with the developer team. They can
take the HTML code put in their favorite designer tool like dream
weaver, front page etc and design independently. If we have server
controls these designer tools do not identify them easily.
Reusability of code behind class
If you watch any professional ASP.NET Webform project you will notice
that code behind class is where you have huge amount of code and the
code is really complicated.Now this code behind page class inherits from
“System.Web.UI.Page” class. This class is not a normal class which can
be reused and instantiated anywhere. In other words you can never do
something as shown below for a Webform class:
WebForm1 obj = new WebForm1();
obj.Button1_Click();
Because the “WebForm” class cannot instantiate with out “request” and
“response” object. If you have ever seen the “ButtonClick” events of
“WebForm” they are as shown in the code below. From the code you can
know how difficult it is to instantiate the same.
protected void Button1_Click(object sender, EventArgs e)
{
// The logic which you want to reuse and invoke
}
Solution for this problem: “GET RID of SERVER CONTROLS and CODE BEHIND”.
Unit Testing
As said in the previous section you cannot instantiate behind code
straight forward it’s very difficult to do unit testing or I will say
automation testing on the code behind. Someone has to manually run the
application and do the testing.
When we work with data in Asp.Net MVC, one important task is passing data from Controller to View for displaying. So how many way can we pass data from Controller to View? and which way should we choose? We are going to see in this post.
There are 3 ways:
ViewData
ViewBag
Strongly Typed View
ViewData
ViewData is a dictionary, which will contains data to be passed between
controller and views. Controller will add items to this dictionary and
view reads from it.
<b>Employee Details </b><br /> Employee Name : @emp.FirstName @emp.LastName <br /> Employee Name : @(emp.FirstName emp.LastName) <br /> Employee Name : @ViewBag.Employee.FirstName @ViewBag.Employee.LastName <br /> Employee Name : @(ViewBag.Employee.FirstName + " " + ViewBag.Employee.LastName) <br /> Employee Salary: @emp.Salary.ToString("C") </div>
Problems with ViewData and ViewBag
ViewData and ViewBag is a good option for passing values between
Controller and View. But in real time projects it’s not a good practice
to use any of them. Let’s discuss couple of disadvantages of using
ViewData and ViewBag.
Performance issues
Values inside the ViewData are of type Object. We have to cast the
value to correct type before using it. It adds additional overhead on
performance.
No Type safety and no compile time errors
If we try to cast values to wrong type or if we use wrong keys while
retrieving the values, we will get runtime error. As a good programming
practice, error should be tackled in compiled time.
No Proper connection between Data sent and Data Received
In MVC, controller and View are loosely connected to each other.
Controller is completely unaware about what’s happening in View and View
is unaware about what’s happening in Controller.
From Controller we can pass one or more ViewData/ViewBag values. Now
when Developer writes a View, he/she have to remember what is coming
from the controller. If Controller developer is different from View
developer then it becomes even more difficult. Complete unawareness. It
leads to many run time issues and inefficiency in development.
Understand strongly typed Views
Reason for all three problems of ViewData and ViewBag is the data type. Data type of values inside ViewData, which is “Object”.
Somehow if we were able to set the type of data which need to be
passed between Controller and View problem will get solved and that’s
wherestrongly typed Views comes to picture.
Step 1 – Make View a strongly typed view
Add following statement in the top of the View
@model WebApplication1.Models.Employee
Above statement make our View a strongly typed view of type Employee.
Step 2 – Display Data
Now inside View simply type @Model and Dot (.) and in intellisense you will get all the properties of Model (Employee) class.
Step 3 – Pass Model data from Controller Action method
Change the code in the action method to following.
Although it's a best practice to use strongly typed view when we need to pass data from Controller to View, it's OK to use ViewBag when appropriate. To be more specific, anything you want strongly-typed in your view, then, needs to be on your
model. If you have something you don't want on your model or that is
one-off, then ViewBag is provided as a generic catch-all for all non-model data, which is why it is a dynamic.
I got a weird error in Xcode 5.1 today while developing a Mac App which serves as a data entry tool for an iOS app: Redefinition of ‘Category’ as different kind of symbol. The weird thing is that the Mac App builds and runs fine, but when I import the model over to iOS I get an error at compile time:
The puzzle’s solution lies in something called “Namespacing”. Not that I even remotely care or pretend to understand this, but in a nutshell it means that the name Category is reserved and already defined in /usr/include/objc/runtime.h:
/// An opaque type that represents a category.typedefstruct objc_category *Category;
What that file is or where it comes from will forever remain a mystery to me, just like why it’s not a problem in a Mac App. I could probably try to figure this out for the rest of my days but really: life’s too short as it is. Let’s just
rename the Category entity
regenerate all NSManangedObject sub classes
remember Category as an evil string for the future
and be done with it. Note that you must rename the Entity as well as the Class it creates, and for good measure re-create all your NSManagedObject subclasses:
I guess that’s why at the beginning of a new Xcode project we have the option to prefix all our classes (which would undoubtedly avoid such problems in the future).
A small problem is after the MPMoviePlayerController plays the video, the status bar disappears. We can see the status bar is lack of time, battery notice… It may cause some other bugs such as the frame is calculate wrong.
The problem is the controlStyle of the MPMoviePlayerController. Except using MPMovieControlStyleFullscreen, use MPMovieControlStyleEmbedded
