I'm writing a Delphi application which has an intergrated Remote Desktop ActiveX Control (a.k.a MSTSCLib - but specifically TMsRdpClient9). I am able to successfully connect to and log in to the target machine, and I am able to Disconnect from the target machines using RDPClient.RequestClose() or RDPClient.Disconnect(), but I need to know how to send a Logoff/Logout command to the RDP Client.
I have gone through every interface of the control, and I cannot find any command which seems to do this functionality. I have also gone through the documentation linked above, and the method I need to use seems to elude me.
I have also searched Google, and Stack Overflow for similar questions, and have found none.
Can somebody please give me a hand
Related
This is not a question, but I didn't find a section where to put this experience to help others.
Problem:
Using ExpressPrinting system components (DevExpress VCL), when connecting via RDP with the option enable sharing of user's local printers, these printers are not listed in the device selection dialog. Only printers installed on the Remote Server (if any) are available.
Solution:
This was raised by the user "Luis Madaleno" in the official DevExpress forum, and it was the user himself who finally found the following solution:
"...before calling TdxComponentPrinter.Preview: "
if (Printer.Printers.Count <> dxPrintDevice.Printers.Count)
then dxPrintDevice.Refresh;
More on the "why?" of this problem, you can find it in the original query raised in the official forum of the product.
Technical Note
This situation generally occurs when the configuration of the user account launches the execution of a program (.exe) when the session is connected, that is, the user "does not see" the Windows Remote Desktop and directly launches a application.
The user can only interact with the printers through the dialog boxes offered by said application.-
Finding this solution took me a long time.
That's why I share it here. I hope it is helpful to the community.
Best regards,
I have a ActiveX control hosting a flash-player which is in turn running a flash file trying to access data from a web-address.
In an old Windows Application version of my application everything works fine and the flash file is able to access the web-content.
However, in a newer Console Appliction version of the application it can no longer access the web-content.
Any ideas what might be causing this? Is there some kind of difference between a Windows Application and a Console application in terms of security/permissions that might affect an ActiveX hosted flash-player?
I'm using Windows 7.
First of all - how did you manage to get an ActiveX into a console application? :) I think ax needs window handles and all such things...
Anyways, there are different kinds of sandboxes from the Flash player perspective, what you are seeing is the "local not trusted" kind. In order to "trust" the SWF that issues the request you would need to use this page to confirm that the location where SWF comes from can communicate to the internet.
Doing so may be a hindrance for the user, but if this is the case, you could write the trust files on your own. Example
We are going to develop a client-server application where all the office documents will be stored on the remote server.
The problem is that users need to edit these docs very often.
The standard solution is:
download
edit locally
upload
But it is very inconvenient and would cause high traffic, cause docs are very large.
Is there any solution to edit documents right on server?
E.g. some remote OpenOffice installation which we can connect somehow?
Thanks in advance!
Unless you can give your users RDP sessions on Windows or VNC (or X windows?) sessions on Linux you're going to be stuck with downloading the document to edit locally (in one form or another) then upload again.
There may be some HTTP/browser based solution but because it's HTTP you're going be to pulling all of the document back to the browser to edit then posting back to the server, it pretty much defeats the purpose.
As pointed out by Kev, one solution would be some sort of remote access software to access a copy of OpenOffice.org running on the server. There is for example a VNC viewer that will run as a Java applet in a browser (http://www.realvnc.com/support/javavncviewer.html ), that might do the trick.
Another option would be a server-based office package, a la Google docs. There are some available, but none with the full feature set of OpenOffice.org, so this is probably only an option if you can restrict to that feature set. If you can, it could work quite well.
#UPDATE:
OK FOR ANYONE ELSE WHO IS SEEKING ADVICE ON THIS ISSUE...
So far, the best thing I have found is to download yourself a copy of pGina and for 2k/XP modify the GINA, and for vista/win7 you will need to create custom login credentials (pGina have the tools/samples to interface with the Vista/Win7 architecture).
to confirm -- it appears that this is what Novell are doing with Vista/Win7 rather than the traditional method of replacing the GINA (like in 2k/XP)
If anyone else comes up with a way to run an application on the logon screen in Win7 please post it.
Ok I'm writing some vb6 software that requires input before the user logs on to the system.
Basically I want to run an application on the Windows logon screen where the user can interact with the program. At present I have the application running as a service allowing to interact with the desktop, but it is still now showing.
I know that "Allow service to interact with desktop" will work in Windows 2000 / XP, I'm running Windows 7 - I am also aware that services cannot directly interact with a user as of Windows Vista - saying this, are there any other methods to get my application running on the logon screen. Novell does it
Does anyone have any other ideas to get this working?
You can only do this if you are authenticating the credentials yourself. Prior to Vista, this was done via GINA, but since Vista, you need to write your own Credential Provider.
The reasons behind this are buried deep in the security principles -- Ctrl-Alt-Del will only ever bring up the window station associated with login (etc), and no other application can get to that window station (so you can't create a fake password box over the top to scrape passwords, for instance).
Without knowing why you think your service needs to interact with that desktop, it's difficult to advise further, but it might mean that your design is broken somehow.
Service isolation will probably prevent you doing this from a service.
Pre-vista Novell and the like would probably have used GINA, which was replaced in vista; http://msdn.microsoft.com/en-gb/magazine/cc163489.aspx
The only way I know of would be to write your own msgina.dll.
It can get dicey during testing though. Any mistakes can mess up your OS so bad that a complete reinstall becomes necessary.
I am working on some Automation Project where one needs to perform some action related to display resolution.Change the Display resolution , Lock the Desktop and then Unlock Desktop again to check that resolution remained same.
I am able to perform LockWorkstation but unable to have any thing for Unlock Workstation.
Can any body help me regarding unlocking Display with help of C# and in Win 7 ?
I heard of GINA dll which can help ,but I dont know anything about it.Can this be used for Win7 and .NET 3.5?
Thanks
_Prat.
I don't think that doing this is technically feasible. GINAs were deprecated after XP and the new way to provide custom authentication in Vista/Win7 is to use the ICredentialProvider
interface. Even if you get this working you'll still have to somehow send the the secure attention sequence, i.e. ctrl-alt-delete, to initiate the logon. Sending ctrl-alt-delete programmatically is itself something that is difficult to do and not really supported.
This sounds like a lot of work for some automation and probably won't have much ROI. Can you test this by logging the user off completely and then logging back in? If so, then you could set your test machine to auto-logon the user. When you log-off it will shut down the session and then promptly log the user back in and you could check if the resolution is what you expect.