-
-
Check it out here.
[Update: btw, here's the link to the interview]
-
-
Then you won't be able to use XP anymore...
-
-
Jason (thanks!) has added a comment saying that PowerShell was released yesterday. here's the link for the x86 and x64 downloads. btw, can anyone please tell me why it isn't listed on the PowerShell download page?
-
-
It seems like Rama did it again! Get the complete story from here.
-
-
Well, today while reading a post in the AJAX forums, I've noticed that this question popped up again. Which should you use (if you have an option). well, it turns out that you should use typeof when you can (and I've searched for an old post I've read in the past to confirm it)
-
-
I've just noticed this after reading Karsten's post.
-
-
Currently, it's 20:30 (GMT) and I still don't see any sign of either of these products: PowerShell for Vista and Office language pack for Portuguese. Any good excuses for failing on this items? I mean, if i'm not mistaken, PowerShell for Vista should debut till the end of this month (thinking about this, it's strange that this great shell was released only for XP and Server 2003 - after all, it was part of Vista during several CTP releases) and there's already a Portuguese-Brazil language pack. is it so hard to 1.) give us a release of PowerShell to vista (please, please, please!) and 2.) for the love of God, please put a Portuguese (for Portugal) office language pack!
thanks!
-
-
Well, i've been planning to buy it for some time, but guess what? it's free since December and I've finally got the time to install it. Now I'm using it for everything (yep, even for email since it's able to synchronize with Outlook)!
-
-
Some time ago, Rama gave us (users of the AJAX forums) a good tip: Using http://localhost.:12... or http://localhost./.... forces IE to use Fiddler to make the request! The problem is that IE7 is smart (in fact, maybe I should say that in this case, it's behavior is really annoying) and even if you configure it to go through a proxy, it will always make a direct call if it detects a localhost call.
Before knowing this, I was forced to use firefox or to create a web app in IIS. This little trick will save me lots of time :)
btw, Rama has some cool posts on his blog (I say some because there's only five posts there :( ). Lets hope that he starts writing frequently!
-
-
As you've heard, the AutoComplete has been moved to the ajax toolkit. although this sounds like a logical decision (yes, I'm agreeing with MS on this one), it made my pages stopped working. the bad news is that in order to get the client part working, you do need several imports from the ajax toolkit. here's a demo page:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Untitled Page</title>
</head>
<body>
<script type="text/javascript" src="../MicrosoftAjax.debug.js">
</script>
<script type="text/javascript" src="blocking.js">
</script>
<script type="text/javascript" src="common.js">
</script>
<script type="text/javascript" src="timer.js">
</script>
<script type="text/javascript" src="BaseScripts.js">
</script>
<script type="text/javascript" src="PopupBehavior.js">
</script>
<script type="text/javascript" src="autocompletebehavior.js">
</script>
Introduza o nome: <input type="text" id="nome" />
<script type="text/javascript">
Sys.Application.add_init( handleInit );
function handleInit( sender, e ){
$create(
AjaxControlToolkit.AutoCompleteBehavior, //tipo de componente
{"completionInterval": 2, "minimumPrefixLength":1,
"serviceMethod": "ObtemPalavras", "servicePath":"autocomplete.asmx" }, //propriedades
null, null, $get("nome") );
}
</script>
</body>
</html>
well, that's what happen when you start using CTPs :) at the end, and if you do want to keep your pages working, you do need to make some changes...
-
-
Today I've run a little experience after reading (and writting) some posts on this thread of the ASP.NET forums. Following Matt's info, I've extracted the js files from the Preview dll and I've re-run my previous tests. Matt is almost right: they've really fixed all the bugs but one: the insidious ListView bug. I'd be happy to know why it's still there...anyone?
Yesterday rantings and rumblings were replaced today with a nice feeling that everything is just as it should (I mean, almost: i still haven't forgotten that ListView thingy!). I'm sure that the guys of the team will still "kill me in sight" but I'm not worried because I think I was right about complaining (after all, it's not my fault that there's been a sync problem between the embedded and the external js future files). Another reason why i'm not worried is that I do live far far far away from Redmon:)
I think it's safe to say that all the other items I've mentioned are now solved. After all, you do listen. thanks!
-
-
After my initial reading of Mike's post, I was under the impression that modifying web parts without a postback was an AJAX 1.0 feature. Unfortunately, after reading his blog post, I understood that this scenario isn't supported in this release. So, you can do 1 and 3 (cross-browser drag and drop and updating contents of the web part without full postback) in the current version, but 2 (modifying web parts without full postback) will only be possible in Orcas (and this is only a possibility).
-
-
After spending the day ranting about the RTM version (well, in fact, the problems are with the future bits), it looks like there's still hope. According to Matt, there seems to be a problem with the build process. Lets wait for the correct bits. I hope that at that time I can say that it was all a misunderstanding.
-
-
Yeah, another bug, reported by a long time ago. it's still there...the original code tries to load (and to save) the profile properties through the appli function method. here's the original code:
this.load.apply(this, parameters);
Well, not sure on what's the point of writting that code. the only thing i can say is that writting this:
this.load(parameters);
works but the previous doesn't!
-
-
If you're using the client authentication services on an ASP.NET page that has a ScriptManager control, then there's nothing here for you. it's safe to move on :)
On the other hand, if you're using the client side files and you do need to integrate your page with the authentication of ASP.NET, then keep reading. In the CTP, the client side class initialized itself with the path to the service in the server side. As you know, the service is embedded in the System.Web.Extensions.dll and you can only access it if your request has a specific path. So, the problem is knowing the path to the service so that you can set your AutorizationService with the correct path.
In the current release, the authentication service only responds to the Authentication_JSON_AppService.axd name and the url must point to the top folder of your web app. For example, if you've got an html page at the top of your web folder, you only need to indicate that path. On the other hand, if you have a page inside a subfolder, you do need to make sure that you're forming the correct path. Here's an example of initializing the path property of the AuthenticationService object from a page placed inside a sub-folder of the top web folder (note the ../ used in the path):
Sys.Services.AuthenticationService.set_path( "../Authentication_JSON_AppService.axd" );
-
-
Yep, another problem with the future bits! If you try to use this class from xml-script, you'll get an error that says something like this:
Error: Sys.ArgumentTypeException: Use isDomElement with a null type for element properties
e.g., for descriptor use { name: 'foo, isDomElement: true, type: null }
Now, you can't get a more explicit error message than this one. So the real question is why the future bits have the following descriptor for DraggableListItem
Sys.Preview.UI.DraggableListItem.descriptor = {
properties: [ {name: 'data', type: Object},
{name: 'handle', type: Sys.UI.DomElement},
{name: 'dragVisualTemplate', type: Sys.Preview.UI.ITemplate} ]
}
Replacing the bold line with this makes everythign work again:
{name: 'handle', type: null, isDomElement: true},
Oh, and since you're at the previewdragdrop.js file, you should also make the following changes:
- the descriptor for the handle property of the floatingBehavior is wrong (you need to make the some changes as the one you've made to the DraggableListItem's handle property)
- the checkCanDrag method has a bug where it tests the undraggableTagNames variable. You should change the line undraggableTagNames.indexOf( tagName.toLowerCase() ) to Array.indexOf( undraggableTagNames, tagName.toLowerCase() )
I'm starting to get upset! Can anyone please tell me why you've decided to start breaking the future bits? I know that they aren't supported but if you're going to break it in purpose, then it would probably be better to just remove them! don't you runt tests? for the love of god...I've just sepnt a morning running some simple tests and fixing you code! this really shouldn't be happening, should it?
-
-
Again, another bug that has been propagated to the january future bits... the PropertyKey is being defined in the glitz file as Object.
Again: this property should be defined as string, not int. This is becoming a routine...I know I'm talking about the future bits, but this kind of errors is becoming unacceptable (specially if you think that most of them aer well known for months!)
-
-
This is one of the things that it's really difficult to understand. The ListView client control has been exposing this bug for several months now. I've put in the forums, I've sent emails to the team members during the CTPs/betas, but it seems like no one is able to solve it.
the problem: if you click over the 1st item of the listview after it has loaded, the line isn't selected! To get a selection on the 1st line, you must first select another line and only then you can select the first line. It looks like they did change the code in this version, but the bug is still there...
Well, i knew that my english wasn't good, but i never thought it was so bad that it couldn't be understood. at least now i know that...
-
-
In previous versions of the AJAX extensions platform, you could use this control to call remote services exposed by a handler or a data service. The only restriction is that the server component needs to return data in JSON format because that's the only format the control "understands".
So, if you had a web service and didn't want to build a data service, you just needed to set the serviceType property of the client control to Handler and use the correct url. I mention correct url because the handler used to process the request on the server was chosen after parsing the url of the request (for instance, in previous versions you could use something like webservicepath/js/methodname - the /js made it go through the rest handler).
Things have changed and now the Content-Type of the request is used to see if the current request should return json or soap. The problem with this is that my old code (which is based on the datasource control) stop working because the url path hack i was using was no longer valid. So,. how can i call a web service (not a data service!) from a datasource control? easy: you need to handle the invokingRequest event of the WebRequestManager object and set the Content-Type header to application/json.
Here's a small demo page that does just that:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Untitled Page</title>
</head>
<body>
<script type="text/javascript" src="../MicrosoftAjax.debug.js">
</script>
<script type="text/javascript" src="../Microsoft.Web.Resources.ScriptLibrary.PreviewScript.debug.js">
</script>
<script type="text/javascript">
Sys.Net.WebRequestManager.add_invokingRequest(
function( sender, e ){
var req = e.get_webRequest();
req.get_headers()["Content-Type"] = "application/json; charset=utf-8"
}
);
</script>
<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
<dataSource id="mySource" autoLoad="true"
serviceURL="WebService.asmx/ObtemAlunos" serviceType="Handler" />
</components>
</page>
</script>
<input type="button" value="Mostrar dados" onclick="handleInfo()" />
<script type="text/javascript">
function handleInfo() {
var source = $find("mySource");
if( source != null ) {
var tbl = source.get_data();
for( var i = 0; i < tbl.get_length(); i++ ) {
var row = tbl.getRow(i);
alert( row.getProperty("Nome") + " " + row.getProperty("Idade") );
}
}
}
</script>
</body>
</html>