After a couple of times changing and saving a .cshtml file, the view starts to get frozen.
I recorded a video, you can check it right here.
Does anybody know how to solve it?
this is a known bug in VS for Mac and it will be fixed in an upcoming release. You'll need to update to the latest version (I'm not sure when that will be released, but hopefully soon).
Sorry for the inconvenience!
Related
I have an app I have been working on that was running fine.
I upgraded to the latest Xamarin with mac support and now I get an error when I try to use HttpUtility.ParseQueryString.
I have an App.config file and it is telling me that it can't parse it, but this happens when trying to call ParseQueryString. How are those 2 related?
I thought I had found the problem because my app also has a ServiceReferences.ClientConfig file for http client settings. I copied my App.config section to the ServiceReferences.ClientConfig file and that fixed it until I went to show my fellow dev the new error.
The new error was saying something about Path.Combine path1 being null.
I looked up that error and found a reference to a page talking about MacSupport in xamarin here: https://searchcode.com/codesearch/view/8556026/
I don't know if they are related, but that is the closest I found to the stack trace I was seeing.
Can anyone tell me what changed in Mono 4.8 for Mac in Xamarin that would cause an issue with HttpUtility.ParseQueryString and how to solve it?
System.Configuration is a common point of pain during mono upgrades, as it's behavior sometimes subtly (or not so subtly) changes.
You'll need to post a much larger chunk of information here for anyone to be able to help you.
Or you could post on the XM Forms or file a bug if you believe this is a bug, as those are a more appropriate place for such reports.
This question is still getting a lot of upvotes. So look at Update3. once you have upvoted, commented, answered, please please please file a radar
Viewing a nib / xib, modifies the file, forcing me to either commit the change or undo the change. This is not an issue, until there are merge conflicts.
Detail:
I work in a team of 5 iOS developers, and the last few versions of XCode, we are experiencing an issue with the .xib / nib files getting touched / modified when anyone opens the file (without making any changes).
If one developer thinks "screw it, let me checkin whatever modifications xcode does" and checks it in, it doesn't stop there. the same file on two different machines (with the same version of XCode and MacOS) will again be touched/modified when another developer views that nib.
The thing that usually gets modified in the .xib file is this
<key>com.apple.ibtool.document.version-history</key>
<dict>
<key>interface-builder-version</key>
<dict>
<key>com.apple.InterfaceBuilderKit</key>
<string>2844</string>
<key>macosx.version</key>
<string>12C60</string>
</dict>
</dict>
<key>com.apple.ibtool.document.warnings</key>
<dict/>
But other than that it also modifies or moves around existing key-value pairs within the .xib file.
I have searched a lot on SO and Google, and I haven't seen many posts about this issue.
I had a nightmare of a merge conflicts when I upgraded all nibs to handle the iPhone5 screen, which in itself wasn't too complicated, but got a ton of merge conflicts due to the document versioning.
Deleting code I didn't understand, led to xcode crashing when I tried opening the nib. (I have fixed this for now, by reverting to what it was earlier)
Any advice on how to avoid this issue, is appreciated!
Update: Have noticed that this is not resolved yet, and still getting upvotes quite often. I am just curious, do any of the storyboard projects experience the same issue? (I haven't worked on storyboards yet).
Update2: To all those who are experiencing the same issue, please file a Radar even if you get a response saying there is an existing radar. it helps bubble the issue to the top and the gods of XCode will address it only then.
Update3: I still see quite a few upvotes on this thread, and the apple bug report is still open. So, after upvoting this question, please file a radar, with details I have mentioned in the question (and/or add your own explanation)
Update4: This question is still getting a lot of upvotes. So look at Update3. once you have upvoted, commented, answered, please please please file a radar
Update5: Per info from Apple Engineers at WWDC 2014, this issue has been fixed in Xcode6. I'll update this question (and probably close it) once I confirm that this has been fixed.
Update6: Hoping to see this fixed. Will be asking this at WWDC2015 (through someone I know who's going there). Would be great if the other lucky ones who got a WWDC ticket can also do the same at WWDC 2015
Update7: Xcode 7 is here, and so is this bug :( The original radar report (11533872) is still open
Version 4.6.3 of Xcode resolves this issue. However, as the comments state, you all need to be running that same version. If four developers are on 4.6.3, and one is on a previous version, then that developer will experience the same issue. However, if they do not commit that change then it will not affect the others.
The two Xib keys affected are:
<string key="IBDocument.AppKitVersion">1187.39</string>
<string key="IBDocument.SystemVersion">12E55</string>
So, bottom line, get everyone on the team to update to Xcode 4.6.3.
Try updating the XIB's "Document Versioning: Development" setting:
Xcode: File Inspector: Interface Builder Document: Document Versioning: Development
to at least "Interface Builder 3.1".
I'm trying to update my storyboard file and it doesn't open correctly due to the following error:
".xcodeproj cannot be opened because the project file cannot be parsed.".
I'm on the latest version of MonoTouch, so I don't think a previous bug can be attributed to this. Does anyone have any ideas?
Cheers,
Davoc
It looks like this bug, which has already been fixed (but is not in a released version yet).
Comment 2 has a possible workaround (but if it doesn't work you should file another bug, since it's not the same issue).
I have a class that inherits from TTTableViewController, and overwrites the "createDelegate" method to use the TTTableViewDragRefreshDelegate instead of the default Delegate.
The problem that I am seeing right now is that there is some header space that appears before my table content (supplied by data source, of course) for iOS 5, but this isn't there on pre-iOS 5 versions.
I searched around and found this article (http://stackoverflow.com/questions/6651367/how-to-make-the-blue-bar-on-the-top-disappear-for-tttableview-with-list-datasourc), but it doesn't quite help me as I did not overwrite tableView:viewForHeaderInSection: method.
What I have noticed is that for all my TableViewControllers that have this problem, they all seem to overwrite the "createDelegate" method and return TTTableViewDragRefreshDelegate, as mentioned above.
My question is: anyone ran into the same issue? How can I fix this problem?
Okay, figured it out. The problem is with an old three20 library that I was using. Once I upgraded to the latest, it was fixed.
Internet Explorer 9 was released today, and I decided to check a few Magento sites we build in the last couple of months to see if everything continues to work with the new version.
But unfortunately it doesn't. I came across one particular problem that is caused by the version of the prototype library which is shipped with Magento, version 1.6.0.3.
It looks like the cancelling events in eventhandlers isn't working.
For example, if you try to log in to a Magento shop, and just leave the login and password fields empty, IE9 submits the form even if there were errors, and the errors disappear after the refresh.
So that's quite a big problem I think.
So my question is: how can we deal with this problem? I see a couple of ways to deal with this:
Wait for Magento to release a new version with fixes
Upgrade the prototype library to the latest version which probably already has fixed the issue
Mess around in the existing library and try to fix the bug in there
Waiting for a new Magento release isn't a good idea because it probably will take a few weeks before there is one, and because it will cause a whole lot of other problems if you are running a very old version of Magento.
Upgrading to the latest prototype library is probably the best idea, but will everything in Magento continue to work with the latest version of prototype, does anybody has any experience with this?
So what's everybody's opinion about this problem?
Any ideas other than mine?
As upgrading Prototype has the potential to break a lot of things in Magento (and, honestly, doing anything in Magento has the potential to break a lot of things in Magento), I created a theme override for my
app/code/design/frontend/{package}/{theme}/template/page/html/head.phtml
file and slapped the following as the first element under the head tag:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
This tells IE to pretend as if it is IE 8, where possible. This solved an issue where, for example, you could not check out and complete the payment process if you only have one payment method enabled, as in IE 9 the fields will all be grayed out.
Note that it really must be the first tag underneath the <head>.
Since upgrading Magento in any way has the potential to cause problems, I feel this is the least intrusive way to solve the issue in the near term.
Solved: http://www.alexanderinteractive.com/blog/2011/10/solving-the-ie-7-ie-9-magento-prototype-validation-bug/
I spent a couple days on this, and discovered the only thing that truly works is disabling things at the form level. This should solve all your problems.
As a quick fix, I think I would take the same approach you are advocating, and upgrade Prototype to a version that does not contain this issue. However, Magento will be coming along with a patch (this is too big to ignore), and at that point, it would be wise to undo your changes and apply the patch they provide to keep in line with normal upgrades.
It is rarely worth it to manually dig in the internals of Magento's JS, so that option seems a bit off to me. There are probably several places where this semantic is used and you may miss some of them.
Hope that helps!
Thanks,
Joseph Mastey
I've updated the prototype.js file to 1.7 and so far it's correct. I dont see any errors. If you apdate and find errors please notify!
The proper fix is in the Magento forums.
In template/catalog/product/view/tabs.phtml, change the line that reads:
ul.select('li', 'ol').each(function(el){
to
ul.select('li').each(function(el){