i want to know if there is any way to change title of inputbox i.e prompt in javascript?
nope, you cannot change the title in the native javascript prompt. you could easily write a function of your own, though, which mimics the behavior of the prompt, but the flow won't be exactly the same (i.e. you'll have to use callbacks, rather than a return value, for the user input)
Something like:
function myPrompt(title, message, value, callback) {
// create form, that displays the title, message, and an input box with the value
// append the form to the dom, probably in some elevated (modal) manner
// if the user invoking myPrmopt didn't specify a callback, don't register listeners
if(typeof callback != 'function') return;
// register listeners:
// if there's a close button, equivalent to escaping out of a prompt:
closeBtn.click(function() { callback() }); // not passing any params
okBtn.click(function() { callback(input.value); });
}
If you are talking about changing the title of the window itself, then what i know it is not possible because this method has only two parameters which do not affect the title of the window. See this for more information.
Syntax:
prompt(msg,defaultText)
But you can not change the title which says"
"page at whatever address says...."
Note: The title varies in different browsers.
No, and not only that: you can't really use prompt any more, at all.
IE7 has removed it(*), ostensibly on security grounds. (I find Microsoft's reasoning somewhat spurious on this, especially compared to a lot of the questionable stuff IE has come up with in the past. But it's too late to complain about now.)
So today, for compatibility, you must use an in-document pop-up that runs asynchronously, with a callback function run on completion, similar to David's example. There are many pre-packaged scripts that will do this for you, but it does require that you re-write your calling code to deal with the response in an inline callback function instead of executing directly after the function call.
In any case, alert/confirm/prompt aren't great for usability (as they make the rest of the browser UI unresponsive), aren't very pretty, and have some sneaky concurrency issues in some browsers. If you can get rid of them for all but the most trivial cases (or debugging purposes), that's all for the better.
(*): actually it's still there, but hidden by a security warning infobar which silently prevents it working for at least the first time. This effectively makes the feature as good as useless.
inputbox.title="insert your text here ?";
Related
A little bit of backstory:
We're trying to address a bug on a local library we have.
I was trying to convince the senior developers of changing naming convention when using word like these:
enable disable hide unhide
because they were using
enable disable hide undelete
We discussed the fact of this being a breaking change and will stop other products from working.
So it was disscused to add the unhide without taking the undelete out so that it does not break anything and in the process, if the user uses either unhide or undelete they should still do the same in theory.
Here comes the programming problem now:
This is my function:
toggleAction(data._id, 'undelete', (err, data) => { // cool stuff }, false)
How can I continue to pass a string (without converting to an array or object) but also start passing 2 values so that the changes have to be made in this file and not in the projects side validating, etc.
Another thing, this function will default if the switch case does not found the string.
Also thought about sending two request at the same time but that's just bad programming.
Also though of fallback to another request with the other naming, but since the switch case will still default if it's not in the options, it will not throw an error to actually do the callback for the next function.
What do you guys think is the right approach for something simple and yet capable of breaking a lot of things.
Thanks in advance.
Kinda opinion based, but it's the wrong approach imho.
I would change the word undelete to unhide only on the rendered websites and keep the internal API the same way until the senior devs can fix the breaking changes.
So the user would see the word 'unhide' on their screen, but the API will still stay 'undelete'.
In more complex applications, you'd use an enumeration list so you can change the labels as many times as you want:
const enum_options = [
'enable',
'disable',
'hide',
'show'
];
// 3 is the index of the word 'show'
toggleAction(data._id, 3, (err, data) => { // cool stuff }, false)
That way the API never has to change when you change the labels to any word you desire. Which will also help alot if you ever have to support multiple languages.
ps:
1) if this is a breaking change, there's an issue with the architecture used.
Fix the issues instead of adding even more fragile code. Switching to like using a string 'undelete-unhide' will still need alot of api changes if the entire app has the word 'undelete' written everywhere at the moment.
2) The opposite of hide is usually 'show', not unhide.
I write a plugin for android browser and follow the npruntime rule to let it support JavaScript method. However, after I call the function of my plugin in JavaScript, I get different identifier number in NPAPI's pluginHasMethod() function. I am sure there is no typo error in my JavaScript code. Is there any idea to debug this situation?
Thanks in advance.
NPN_UTF8fromIdentifier is a function you have to provide yourself to call the correct function on the NPNFuncs that you were given when the plugin initialized.
The NPIdentifier is only guaranteed to be the same during the same browser instance; if you quit the browser and start a new one, it may change.
All NPN_* functions are not real functions; those are the "typical" names that you might use for them, but in actuality you are given a structure of function pointers of type NPNFuncs that will have a function pointer for each of the NPN_* functions; if you want those to actually work you need to create the NPN_UTF8FromIdentifier function, etc, and have it call the correct function pointer.
For more info see http://npapi.com/tutorial and http://npapi.com/tutorial2
I have seen jquery-ui-1.8.11.js verify console.log functionality by doing
if (this.debug)
console.log()
I have also seen people define an anonymous function that is a no-op for browsers with no console logging like IE7.
if(typeof console === "undefined") {
console = { log: function() { } };
}
Is there a technical difference or are both functionally equivalent?
In the first example you've given, this.debug will be a reference to a debug variable in the jQueryUI code. This debug variable will have been set elsewhere, possibly by checking whether console is defined, but also possibly with other settings.
In any case, the first example is specific to the application; if you want to do a generic check to see whether the console is available, you'll need to use the second technique. You don't have to define an empty console object as per the example, but doing it that way does mean that you won't have to do the if() condition every time you want to call console.log().
Having said all of that, I would counsel you strongly to avoid putting any code into production which contains calls to the console. The console should only be used for debugging purposes while you are working on the code. It should not be necessary in final release, and doing so can be a sign that either your code is unstable or you're unconfident of it, neither of which is a good sign if you're releasing the code for live use.
(libraries such as jQueryUI are an exception to this rule, as they need to provide functionality for developers to do debugging while writing code using their library)
Both of those do something else. The first code suppresses logging messages unless a flag is set. The people who develop jQuery UI need logging when working on it, and turn it on. But people using the library don't want to have their console cluttered by log messages from libraries, so it's off by default. It lets you turn off logging even when the browser supports it – that regular users on IE7 don't get script errors is a (possibly intended) side effect.
The second code defines a dummy console.log(), so you can call the method without checking if it exists everywhere. It will not suppress logging on browsers where it's supported.
The second of the two is standalone, not relying on jQuery. In my opinion, that makes it better.
I'm using the Script# library with ASP.NET. I want to listen and respond to the onBeforeUnload browser event.
I am currently intercepting the event like this:
Window.AttachEvent( "onbeforeunload", OnNavigateAway );
...
private void OnNavigateAway()
{
Script.Alert("You're leaving.");
}
But the second parameter to Window.AttachEvent is a DOMEventHandler, which has a return type of void. To use the onBeforeUnload event, I need to be able to return a string value, which the browser uses as the confirmation message.
Is there any way to do this without emitting a script literal or hand coding JavaScript? I would really prefer to stay in the compiled C# -> JavaScript as much as possible.
In case it matters, I'm using version 0.5.5 of the Script# library, which isn't the latest version, but I am restricted to this for now.
UPDATE: DuckMaestro answered my question perfectly, but it still didn't work for me. It is the correct answer to my question in that the compiled JavaScript is exactly what I was expecting and wanting. But it doesn't have the desired effect of causing the browser to issue a warning prompt.
I do have a work-around, though, in case someone else stumbles across this answer and wants to know how I initially hacked it into working. Instead of this:
public delegate string BeforeUnloadDelegate();
...
Window.AttachEvent( "onbeforeunload", (DOMEventHandler) (Object)
new BeforeUnloadDelegate(OnNavigateAway) );
I did this:
Script.Literal( "window.onbeforeunload = this._onNavigateAway" );
This is bad form for a number of reasons. This will only work on the .debug.js class that Script# generates; Script# changes the names in the release version, so the script emitted by the Script.Literal statement won't match up. Also, it negates a lot of the benefits of using Script# in the first place. (For example, using Visual Studio's refactoring tools to rename OnNavigateAway to something else will leave an orphaned reference in the string.) Also, the C# code declares the method as OnNavigateAway, whereas the Script.Literal has to refer to this._onNavigateAway.
Still, if, like me, you're on a deadline and looking for a hack, this is a place to start. If I make any more progress on a more correct version, I'll update this question with the details.
Thanks again to DuckMaestro for answering the question I asked.
I would declare a new delegate type
public delegate string BeforeUnloadCallback();
and then change your attachEvent code to
Window.AttachEvent( "onbeforeunload", (DOMEventHandler)(Object) new BeforeUnloadCallback(OnNavigateAway) );
I'm not positive that will work on 0.5.5, but it's the kind of trick I use from time to time in 0.6.x.
We are using MS Word as a spell checker for a few fields on a private company web site, and when IE security settings are correct it works well. (Zone for the site set to Trusted, and trusted zone modified to allow control to run without prompting.)
The script we are using creates a word object and closes it afterward. While the object exists, a winword.exe process runs, but it is destroyed when the Word object is closed.
If our site is not set in the trusted zone (Internet zone with default security level) the call that creates the Word object fails as expected, but the winword.exe process is still created. I do not have any way to interact with this process in the script, so the process stays around until the user logs off (users have no way to manually destroy the process, and it wouldn't be a good solution even if they did.)
The call that attempts to create the object is...
try {
wordApplication = new ActiveXObject('Word.Application');
} catch(error) {
// irrelevant code removed, described in comments..
// notify user spell check cannot be used
// disable spell check option
}
So every time the page is loaded this code may be run again, creating yet another orphan winword.exe process.
wordApplication is, of course, undefined in the catch block.
I would like to be able to detect the browser security settings beforehand, but I have done some searching on this and do not think that it is possible.
Management here is happy with it as it is. As long as IE security is set correctly it works, and it works well for our purposes. (We may eventually look at other options for spell check functionality, but this was quick, inexpensive, and does everything we need it to do.)
This last problem bugs me and I'd like to do something about it, but I'm out of ideas and I have other things that are more in need of my attention.
Before I put it aside, I thought I'd ask for suggestions here.
I have not found an answer to this problem, and I am disturbed at what the problem implies about Internet Explorer security (I forgot to mention in my previous post the version I am using : IE 7.)
However, I did implement a workaround that I am not happy with, but nevertheless feel more comfortable with than no check at all...
The code now attempts to open another object first, and if that fails the code assumes that Word will not open either and issues an error. From this point on, no more calls to new ActiveXObject() will be made and any attempt at a spell check will result in an error.
try {
oMSInfo = new ActiveXObject('Msinfo32.MSInfo.1');
} catch (error) {
// error handling code not shown...
return;
}
This object does not start a new process when the call to new ActiveXObject() fails. It also does not have a noticable affect on system resources.
If your browser creates an instance of an object, the object itself is not blocked by the browser security policies, except it is a security leak.
Try "application.visible=true", or "application.show()" to find out, where the application is asking for user interaction.
Hint: 'typeof application=="undefined"' means, the variable 'application' is not defined, where 'typeof application=="unknown"' means, more or less, it is a defined variable, stuffed with an external, proprietary object and if you really need to know how to handle it, read the manual -- pressing [F11] in any open window of the mentioned application could help in that case.
Might be a useful resource: https://learn.microsoft.com/en-us/office/vba/api/Word.Application