I have a script that is throwing and error when I issue a ControlGet.
OtPtVar := AfxWnd422
strMPP := Material Planning Profile
ControlFocus,%OtPtVar%,,%strMPP%
Control,Show,,%OtPtVar%,,%strMPP%
These all work but when it gets to the next line it throws an error:
ControlGet,sysList,List,,%OtptVar%,,%strMPP%
The control is a grid with five fields row number,Part,Description,Time,Lateness.
`ControlFocus,%OtPtVar%,,%strMPP%`
`Control,Show,,%OtPtVar%,,%strMPP%`
`ControlGet,sysList,List,,%OtPtVar%,,%strMPP%`
The error occurs on the last line.
Thank you.
After searching the AutoHotKey site I found to the following:
Those Afx window classes were custom classes distributed with early versions of MFC, before the "Common Controls" concept was introduced.
Many people have tried to "read" text from them but you CAN'T, not with messages anyway!
They're almost certainly owner-drawn - the text is not delivered by messages, it's "hand-drawn" into the window's DC
...
Messages are a dead-end I think - those who have pursued this problem must have already clocked up several hundreds of hours of monitoring message traffic between them!
So its not possible to get a hold of the control.
ControlGet's List subcommand can only handle standard listview controls, which usually have the class 'SysListView32'.
Did you try AccViewer just in case.
This link mentions textcapturex by Deskperience Software in case that helps.
"AfxWnd42s" Please Help - AutoIt General Help and Support - AutoIt Forums
https://www.autoitscript.com/forum/topic/49057-afxwnd42s-please-help/
There are theoretically process hacker methods,
but I'm not an expert on those, and wouldn't recommend such methods.
And yes, unfortunately when I really needed to, I used OCR once.
Potentially you can do OCR, recreate the text in the same font,
and check for an exact image match as a double-check.
Also, if possible, set the font to one where characters such as capital i and small L are unambiguous.
Related
To clarify, I am specifically asking about how to HANDLE errors when using Shell.Application. Or more to the point, CAN one handle errors, and IF SO, how. The font example is just that, an example of the current situation I am trying to solve. But the question remains, can one handle (not avoid, handle) an error when using Shell.Application? There may well be some subtlety to the answer, I.e in general you can, but specifically not in the fonts example. That seems to be the case, and I am inclined to decide that Shell.Application is old, broken technology that should simply not be used, because it can't be robust in all use cases, which to me says it's potentially fragile in any use case.
I am attempting to refine my use of Shell.Application.CopyHere(), specifically for use installing fonts. What I hope to do is address the occasional error where a font file is corrupt or otherwise not a valid font file.
So far as I can tell from this there really is no way to address this. I can use argument value 16 Respond with "Yes to All" for any dialog box that is displayed. to perhaps get past the error, but with no return code I have no way to log a resulting error. Using .CopyHere() in PowerShell with a Try/Catch doesn't work either. Is this just old technology from a time when Microsoft just accepted things failing ungracefully? Or am I missing a technique that solves the issue?
EDIT: Based on that link I provided, I tried the 1024 argument, Do not display a user interface if an error occurs. Like so
$fontFolder.CopyHere($fontFilePath, 1024)
Doesn't seem to do what it says it does, since I am seeing a dialog that says
Cannot install bogus.ttf
The file ... does not appear to be a valid font.
So, not only not able to get a meaningful error back, but the presence of an error disrupts execution of the script and requires user interaction. Ugh.
EDIT 2:
Not really a minimal code example, since my question is CAN this be done, even before how. But this is what I just tried.
fontFilePath = '\\px\Rollouts\Misc\Fonts\bogus.ttf'
$fontFolderPath = "$env:windir\Fonts"
$fontFolder = $(New-Object -ComObject:Shell.Application).Namespace($fontFolderPath)
$fontFolder.CopyHere($fontFilePath, 1024)
Based on what that 1024 argument claims to do, I would expect this to fail, but also not stop processing while a dialog waits for user interaction.
Also, worth noting that bogus.ttf is simply an empty text file renamed with TTF extension. So, guaranteed not to successfully install a font.
It seems that the Fonts folder, while it does implement Folder.CopyHere, does not evaluate the flags passed in the second parameter. Doesn't seem there are any other standard utilities to install fonts programmatically, or verify the integrity of the TTF non-interactively.
So this leaves us the option of rolling our own Font registration using the Win32 API. Basically, you have to copy the font to the Fonts folder:
# For .NET versions earlier than 4.0, hardcode to C:\Windows\Fonts
# Fonts special folder is new in 4.0
$fontDir = [System.Environment]::GetFolderPath([System.Environment.SpecialFolder]::Fonts)
Copy-Item C:\Path\To\Font.ttf "${fontDir}\Font.ttf"
This next call isn't strictly necessary, as it only adds the font temporarily to your user session, but it does function as an integrity check to see if the font is valid and can be imported. You need to P/Invoke AddFontResource from the Win32 API:
Add-Type -Name Gdi32 -Namespace Win32 -MemberDefinition #"
[System.Runtime.InteropServices.DllImport("gdi32.dll")]
public static extern int AddFontResource(string lpszFilename);
"#
# Returns 1 on success or 0 on failure, if you want your error checking here
[Win32.Gdi32]::AddFontResource("${fontDir}\FontFileName.ttf")
And then register it at the following registry key. This piece is necessary for persisting the font you copied to $fontDir:
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' -Name "FontName" -Value "FontFileName.ttf"
You can programmatically get the FontName using the PrivateFontCollection class, and the Families[x].Name property under that, where x is the index of the font in the collection you want the name for.
To address your edit, there isn't going to be a "one size fits all" approach when it comes to handling errors in Shell.Application. There are multiple reasons to avoid using Shell.Application, such as:
APIs are wrought with legacy behavior, such as using modal dialogs to report errors
Windows standards are implemented inconsistently, such as Fonts ignoring the documented CopyFile flags
Not available in a non-interactive session
The first two points are cases the example in your question hits. The third comes into play in many automation scenarios, especially when a non-interactive service accounts are used to execute commands. There are very few cases where something can only be done via Shell.Application, and as such it's almost always best to avoid it if there is an alternative API. Your font installation scenario is an excellent example of this.
I created a simple RME for TTeeGrid, a descendant perhaps of TGrid in Firemonkey. As shown below, the data are displayed at design time but not at runtime except the headers.
I've been breaking my head over this for weeks already but not luck.
Let me know if you need more details but what you see in the image are all you get.
I just need help to have the data displayed at runtime as shown in the design time.
UPDATE 1
This issue is not the case with TPrototypeBindSource. The data shown in the design time are displayed at runtime. Something is wrong somewhere.
I've never used the TeeGrid before, but the following worked fine
first time for me in Delphi Tokyo:
Download the TeeGrid trial from Steema.Com & install.
Create new multi-device app and place a TeeGrid and a FDMemTable on the form.
Load FDMemTable1 with the file Parts.Fds from the Delphi samples Data directory. Note, I did not then create any FieldDefs as I mentioned in my comment earlier as what I'm describing works without them.
Set the DataSource property of TeeGrid1 to FDMemTable1. TeeGrid1 immediately
creates columns for each of the Parts fields and populates them with data - see
screenshot below. I don't ordinarily include screenshots but in this case thought
I would as what I got was so clearly at odds with what you've reported.
Your TeeGrid etc are obviously more complicated than mine. so the best I can
suggest is that you backtrack to step 2 and see if you can replicate my result
with your data (either at design time or run time). It might be worth loading
your FDMemTable with some data at design time, as my impression is that live bindings
is less grief-prone when the datasource has some data.
Incidentally, fwiw the results of my own attempts to set up live bindings even with a regular TGrid have been rather patchy, until I discovered that instead of messing with the LB components myself, simply starting with a fresh TGrid, right-clicking on it and leaving the Live Bindings Wizard
to do its stuff consistently works fine.
I have been working on creating appointments from Powershell in Outlook. Everything seems to be working with the exception of being able to set the appointment.RTFBODY. It looks like it is stored as a byte array, but despite my best efforts and many attempts I have been unable to set it. Any suggestions would be much appreciated.
http://pastebin.com/kQvGfNRS
Edit: I was able to find what could be a similar issue. https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5dba0d12-94e8-47a5-b082-93d3693e2a47/cant-set-the-rtfbody-of-an-appointmentitem
"I assume you add a wrong version reference. If you add Microsoft.Office.Interop.Outlook 12.0, I could reproduce your issue. I suggest you remove this reference, and add Microsoft.Office.Interop.Outlook 14.0."
Also found this: Outlook AppointmentItem - How do I programmatically add RTF to its Body?
from the link in your question - "it is just a known problem in OOM - setting the RtfBody property using early binding works. Setting through IDispatch::GetIDsIfNames / Invoke does not."
Powershell always uses late bindings (i.e. you cannot declare a variable as an instance of a particular object. e.g. AppointmentItem).
I'm pretty sure about the answer to this, but I'm trying a variety of things to get a very stubborn project to work. One idea was to try to run code through a control without defining it on a form.
So, for example, my original code looked like this:
frmProcess.MyViewer.MaxPageSize = 100
frmProcess.MyViewer.ResetPages
frmProcess.MyViewer.AddPageToView "C:\TestPage1.txt"
I've changed it to:
Dim objViewer As MyViewer
objViewer.MaxPageSize = 100
objViewer.ResetPages
objViewer.AddPageToView "C:\TestPage1.txt"
I get an error window with "Run-time error '91': Object variable or With block variable not set".
But there doesn't seem to be a way to 'set' this control. Is this just impossible, or is there another way to do it that doesn't require a form?
EDIT: I ended up abandoning this entire path of activity, as an alternate solution was found that got around the problem I was having with this form freezing. I don't want to delete this question in case someone else comes along and can benefit from the answers, which are potentially useful.
Try this on a form.
Dim objViewer As MyViewer
Set objViewer = Controls.Add("MyViewer", "MyViewer1")
objViewer.MaxPageSize = 100
objViewer.ResetPages
objViewer.AddPageToView "C:\TestPage1.txt"
I've had similar situations in the past. If all else fails and you have to use a form you can do something crude like
1) Set the .Left property of the control to a negative number (like -10000) so the control doesn't appear on the form, the user can not see it
2) Make the entire form not visible..
ActiveX controls normally expect a number of services from their containers, for example persistence. They are also "packaged and marked" in ways that set the kinds of instantiation they support.
See Introduction to ActiveX Controls.
While it is perfectly possible for a control to be created in such a way as to make many of the available services optional, most controls are created from template code that requires a number of them. And most controls that are "visible at runtime" are going to require container services.
However that doesn't mean a control can't be designed to support containerless instantiation. A well known example of such a control is Microsoft Script Control 1.0 (MSScriptControl.ScriptControl) which can be used either way.
This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau