var dataTransferManager = Windows.ApplicationModel.DataTransfer.DataTransferManager.getForCurrentView();
dataTransferManager.addEventListener("datarequested", function (e) {
var request = e.request;
request.data.properties.title = "Share Link Example";
request.data.properties.description = "A demonstration that shows how to add a link (URI) to share.";
request.data.setUri(new Windows.Foundation.Uri("http://www.google.com"));
});
For some reason, if I click on the Share charm, it just hangs on "Getting info from GodVine" (GodVine is the name of my app). It used to work, then all the sudden stopped working. Am I doing something wrong?
I suspect you stopped a debug session while on a breakpoint inside the datarequested handler. If you stop a debug session inside of the datarequested handler, there is a bug that breaks the Share Broker. The "easiest" way to reset thing is use Task Manager to stop and restart explorer.exe.
on an elevated command prompt - taskkill also comes handy.
- taskkill /F /IM explorer.exe
- start explorer.exe
Related
I use tmux 1.6-2 on a Debian 7.6 (wheezy).
I open a new session and start a long running script that gives updates in form of a progress bar and an activity indicator (spinning bar: /-\|/ ).
When I detach and reattach everything is still fine. But after some random time when I reattach the screen content is stuck. No spinning bar, no progress. I looked into the following:
I can see in top that the process is still running
I can successfully enter tmux commands (like new window, detach, etc.)
I can kill the script with Ctrl-C, but the tmux screen doesn't change
Ctrl-S and Ctrl-Q (like suggested in other threads) doesn't help
Any help is very much appreciated.
I managed to unfreeze my tmux session by running choose-client command from tmux's command line <prefix> :
where prefix is C-b by default
I found the solution in the bug report (by Taisuke Yamada).
I have a program written in vb.net. After I build, I want to launch an interactive batch file that executes a psexec command remotely. How can I do that?
this is my post build event:
call "$(ProjectDir)ExecOnGw.bat"
And this is my batch that if it runs in a normal command prompt, execution is ok.
c:\Sysinternal\psexec.exe \\gateway "C:\Remotepath\mybatch.bat" -u mydomain\myuser -p ******
pause
This batch calls another batch on a remote machine that does something, then if I want to exit, I have to press a "q" and "Enter". In a normal command prompt, it works fine. But in a Visual Studio post build event it goes down.
Help me!
I've done this before using the start command. I created a simple pause.bat file to demonstrate:
#echo off
pause Press Any Key
exit
If I put this in the post build event, I see a console that just closes.
call pause.bat
If I use this instead, I get a second console window that takes my input before closing.
start "My Process" /D c:\batch /WAIT pause.bat
Here is info about our technical development environment :
Microsoft Visual Studio Enterprise 2019
.NET Core 3.1
Just to add to #dsway good answer, I used Visual Studio 2019’s macros so that I could keep the directory path as relative:
start "My Process" /D "$(SolutionDir)Scripts" /WAIT blahblah.bat
Right-click on the Project in question
A context menu will show up
Select the Properties option
Select “Build Events”
Click on “Edit Post-build…”
Enter the aforementioned command that I posted above, and tailor it to your needs before pressing OK.
I'm trying to restart a custom IRC bot. I tried various commands :
load.php
daemon load.php
daemon load.php &&
But that makes the script execute inside the console (I see all the output) and when I quit the bot quits as well.
The bot author only taught me the IRC commands so I'm a bit lost.
You can install a package called screen. Then, run screen -dm php load.php and resume with screen -dR
This will allow you to run the script in the background, and still be able to use your current SSH terminal. You can also logout and the process will still be running.
Chances are good the shell is sending the HUP signal to all its running children when you log out to indicate that "the line has been hung up" (a plain old telephone system modem reference to a line being "hung up" when disconnected. You know, because you "hang" the handset on the hook...)
The HUP signal will ask all programs to die conveniently.
Try this:
nohup load.php &
The nohup asks for the next program executed to ignore the HUP signal. See signal(7) and the nohup(1) manpages for details. The & asks the shell to execute the program in the background.
Clay's answer of using screen(1) is pretty awesome, definitely look into screen(1) or tmux(1), but I don't think that they are necessary for this problem.
This line might help you
php load.php &
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.
Can a VB.NET Windows Forms Application be configured so that when run from the command-line, the command-line waits until the application exits before showing the next prompt?
You can change the command to start your application from the command line to:
start /wait YourApplication.exe
In general the command line behavior depends on the subsystem your application is using (Console/Windows). As an Application with the subsystem Windows doesn't have standard input/output streams, there is no need for the console to wait for them.
But you can change your application to be a console app and use your existing forms as usual. This link shows an example.
The code after Application.Run(new Form1()); is only run after the application has been exited. No configuration needed.
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
string s = "test string";
s.Trim();
}
I think the answer is No, but a console application can show forms.
Unless the command-line is your own console app, then no.
I suppose you could create a console app that shelled out to the windows forms app... a bootstrapper of sorts. If the console app were to be launched by command-line, it might do the trick.