When I call up the Notification Center, I get the value Embarcadero.DesktopToasts.???????? as the reporting app for a limited period of time.
If I delete the link created by Delphi in the C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs directory and also the registry entries Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Embarcadero.DesktopToasts.????????
the app name will be correct again after the second call at the latest.
How can this behavior be corrected?
As a side question, in which value can I store a better icon?
For this to work, there needs to be alignment between the registry and a special shortcut to the application.
These shortcuts may be found by running "Shell:Appsfolder".
So, if a shortcut with a similar name as your program already exists, Embarcadero does not create a proper shortcut and notifications show up as Embarcadero.DesktopToasts....
Cleaning up the shortcuts with a similar name as your product may solve your problem.
(Perhaps Embarcadero should not have checked for shortname name, but for the actual content of this shortcut..)
Related
I have successfully packaged a Delphi app in an MSIX container, but I've run into a problem with one of my app's requirements: Upon updating the app from the Store, its background process (a console exe) is shut down (of course) and replaced with a new copy that is designated in AppxManifest.xml to run when the main app is first opened:
<Extensions>
<desktop:Extension Category="windows.startupTask" Executable="CwHelper.exe" EntryPoint="Windows.FullTrustApplication">
<desktop:StartupTask TaskId="CwHelper" Enabled="true" DisplayName="Capture Manager" />
</desktop:Extension>
</Extensions>
This all works fine, but it means that the background exe is left not running until the main app is opened subsequent to the update. This is highly undesirable.
My Internet spelunking of the MSFT docs leads me to think that I should be able to automatically restart the background app by inserting into the above <Extensions>...</Extensions> block a second Extension something like this:
<Extension Category="windows.updateTask" Executable="<some>.exe" EntryPoint="<some entrypoint>" >
</Extension>
So far, I have not been able to discover what should be my (Delphi-created) <some>.exe and its EntryPoint. Indeed, I have not found any example of this specific use of that Extension Category. Can it actually be used in this way by a desktop-bridge app? If so, can anyone give me pointers as to what I should put into those blanks?
Note added: I've tried repeating the exe's name and Windows.FullTrustApplication in the updateTask definition fields and that actually passed Certification, but it generates a fatal downloading error when the Store tries to install it.
Another note added: #StefanWick kindly pointed out that he has published an example of the very thing I need here using MSFT's toolset. Unfortunately, it is not clear to me how to translate his C# and Visual Studio labels into a Delphi app. Any advice on that would be greatly appreciated.
Answering my own question after about a month's research, I found out that the answer for now is "no" because the necessary IBackgroundTasks interface is not (yet?) available to Delphi according to Embarcadero Customer Support.
But the good news is that this is probably not needed because the "right" way to restart an app after a Store update is described in MSFT docs here.
I just downloaded FilzaEscaped, and was scrolling through it and found the carrier.plist for my carrier. If I were to change something (carrier name for example), would it mess up my phone? And if it did, is there a way to backup the original settings and restore if something goes wrong? Thanks
I think that you can freely edit it however tampering with it will make the signature for the file invalid so it might just end up doing nothing at all and revert to its original state. if you want to change the carrier name the values are located in the key StatusBarImages
See here for more info https://www.theiphonewiki.com/wiki/Carrier.plist
you can edit the.plist file if you'd like... however after your next re-jailbreak (perhaps your phone ran out of charge or you restarted your device) the files will revert. The only relevant settings are in the APN section. I would suggest installing carrier update remover, and/or using untetherme 8+ to change these settings.
Is it possible to use Acrobat.MenuItemExecute('Copy'); command with
AVDoc.OpenInWindowEx(FFilename, Panel1.handle, 0, True, 0,0, 2, 0, 0, 0);
in Delphi 7 and Acrobat XI Pro?
If you help me with an example I'll be glad.
I think the answer to this is probably "no" because before calling Acrobat.MenuItemExecute('Copy'), it is necessary to call BringToFront on the window containing the text you want to copy, otherwise the call to MenuItemExecute('Copy') will fail, even when the document is hosted in one of Acrobat's own windows. I don't see how you could do that successfully when the document window is hosted in your app, rather than Acrobat.
However, there are a few things you could add to your q that might assist in getting a better answer. [...]
Update Please disregard my comments in an earlier version of this answer saying that I could not reproduce the behaviour that I could not select text in the window opened using OpenInWindowEx. In fact, I can now select text fine, what I had overlooked previously is that I had set the Enabled property of my TPanel to False.
Unfortunately, I have still not been able to successfully call Acrobat.MenuItemExecute('Copy') and I am beginning to think that there is no way to do this in a hosted window. I have not found a definitive list, but various comments by Adobe staffers that google found make it clear that many MenuItemExecute strings just to not work when using OpenInWindowEx.
However that may not be the only way to retrieve the selected text back into the Delphi app.
If you look at the hosted window using a tool like WinSpy or Window Detective you will see that contained within the panel window is a whole host of Acrobat windows, including an AVL_AVView one with the Window text "AVPageView" which I imagine is the actual window displaying the PDF text.
I think the key to a possible solution is your observation, which I've confirmed, that pressing Ctrl-C in the window copies the text to the clipboard. So far I have not been able to achieve the equivalent in code, using techniques like keybd_event calls, various Delphi "SendKeys" routines and sending a WM_COPY message to the AVPageView window. I'm sure it must be possible, but I haven't yet found a way.
TFS stores information about who created or who activated a work item and for some reason checks its validity whenever the work item is modified.
When a user is deleted from active directory or renamed in active directory, all work items even slightly has connection with the user can not be modified. Usually the error message is something like ...
TF20015: The field 'Activated By' contains the value 'blah blah blah' that is not in the list of supported values.
I've found a blogpost which recommends tweaking the TFS database, which is something not supported nor recommended by Microsoft.
What can be done to resolve this?
Thanks...
e-mre
Caveat: I'm not sure that this will work, and right now I'm not in a position to test it. However, I've had success with this approach on some other fields.
If you use the TFS Power Tools to edit the work item type definition, you should be able to change the Activated By field's rules and add an ALLOWEXISTINGVALUE rule to it. This might allow you to save those records when the AD name changes.
We've used this with some success with the Assigned To field.
I've seen this behaviour. It occurs if someone who activated a work item is removed from Active Directory (leaves the company) or if they change their name (gets married).
It's simple to fix, you just need to change the work item status from Active to Pending then back to Active this will change the "Activated By" field to the person chaging the status and the problem will be resolved.
Are you using TFS 2008? I seem to remember that this issue is fixed in 2010 (but I might have dreamt that)
If you have a lot of work items this blog might have a solution that helps automate the fix.
How can I tell via a Delphi program if the Windows Explorer Taskbar is set to Autohide?
In Windows XP and higher, you can call SHAppBarMessage API with ABM_GETSTATE message.
Syntax:
SHAppBarMessage(ABM_SETSTATE, pabd);
pabd is a pointer to APPBARDATA struct.
header file is: shellapi.h.
If you want to get state of taskbar, use ABM_GETSTATE message.
you can call this api in delphi.
What is is that you really want to find out? Is it because you want to know the area of the screen that is useable?
If so, then I believe you can use the Screen.WorkAreaRect to determine the available screen area, where all (permanent) tool bars etc. are excluded.
Use Win32 shell apis (IsTBAutohide and others)
See Google Groups for undocumented apis.
Never read registry (ans stop removing right answers, it's stupid...)
U have to deal with windows registry because this information is keept in there. Value indicating "autoohide" is written(read) only while user logon /logout ont with his account
Registry key responsible for storing this information is located in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StuckRects2
The only thing in there is settings and it is a 9th hex value
for "autohide on" this value is 03 for "autohide off" it is 02