prognase
Occasional Contributor
Joined 10 years ago
User Profile
User Widgets
Contributions
Re: Control file save dialog, different Windows versions
Hi Alex, now that got me puzzled - without much thinking I assumed that SaveFile is a scripting function as I was leaning more towards the object hierarchy with click here, click there, keyboard interaction etc. But true, those click function are not methods of the objects. Have to read more in the official doc, so far have read the existing books, though they cover less scripting. With the referenced article, I find the screenshot interesting: the selection of dropdown "Encoding" will not be controlled by the looks of it. When I am back at my PC with TC installed, I have to play with that. BTW: changed my Delphi code and it reads the type from extension now, if extension is omitted it picks from the list as a fallback and appends that. This is the logical way anyway, and my solution before was partially nonsense: why save a file with provided name "myFile.docx" as ASCII txt file when the user still has "*.txt" as default value? The (educated) user surely expected Word 2003+. Thanks, Matthias2.4KViews0likes0CommentsRe: Control file save dialog, different Windows versions
Hi Alex, thanks for the suggestion. Didn't know that file type is an optional parameter or that there are overloaded functions. Do you know by any chance where I could find such information? I guess MSDN or similar, but as I am a Delphi guy I have no real knowledge how to find my way there. Currently my Delphi code takes the file type which is not switched when calling from "outside" this way: fileName := SAVEDLG_Grid.FileName; case SAVEDLG_Grid.FilterIndex of 1: saveFormat := gsfASCII; 2: saveFormat := gsfCSV; 3: saveFormat := gsfXLS; 4: saveFormat := gsfDoc; 5: saveFormat := gsfHTML; else saveFormat := gsfUnknown; end; But that code I can change easily and derive type from variable fileName. Thanks for the solution, and if you know MSDN or similar starting point, would be thankful! Cheers, Matthias2.5KViews0likes2CommentsRe: Control file save dialog, different Windows versions
Hi Matt, could you elaborate a bit more? What you do seems to be like what I tried with reading all dropdown list values for file types and then looping over that, i.e. always having the right version with or w/o extension in the string. However, the objects and their child structure differ between the 10 and 8.1 versions, so I would need to know the exact "paths" for each of the dropdowns. Making it more complicated, my license for TC is on 10, TE is on 8.1, and in TE there is no recording, so no easy capturing of the components and their attributes. Very much interested how you approached this issue. Thanks, Matthias2.5KViews0likes0CommentsControl file save dialog, different Windows versions
Hi all, I am having a problem to DelphiScript a series of exports. Windows 8.1 and Windows 10 seem to use different file type entries in the "save as" dialogs of the OS: one shows the description, the other description plus pattern. When testing on different platforms the parameters past have to differ as a result. First I tried to extract the available file types separated by CR/LF from the dialog object (GetPropertyValue) and loop over it, but the dialog object hierarchy differs, so I would need to hardcode the object access depending on the operating system. Then I tried exception handling: try description only, on exception try incl. pattern. However, this stops on the incorrect first try, see the code segments. Is there any way to temporarily disable StopOnError or something similar, or is there a more elegant way to solve this in general, independant of the Windows version executing this? The next OS update or upgrade can otherwise easily make the script invalid. Alternatively I either create a config per OS test environment, or I would need to switch to an OS-independant file dialog with all its style and layout issues. procedure _exportOne (AGrid: OleVariant; AOutFile: string; AType, ATypeAlt: string); begin AGrid.ClickCellR(0, 0); AGrid.PopupMenu.Click('[1]'); try LFH.dlgSpeichernUnter.SaveFile (AOutFile, AType); except LFH.dlgSpeichernUnter.SaveFile (AOutFile, ATypeAlt); end; end; procedure _exportSet (AOutBase: string; AGrid: OleVariant); begin //-- save report in all formats. _exportOne (AGrid, AOutBase+'.txt', 'ASCII', 'ASCII (*.txt)'); _exportOne (AGrid, AOutBase+'.xlsx', 'Excel Document', 'Excel Document (*.xls)'); _exportOne (AGrid, AOutBase+'.html', 'HTML', 'HTML (*.html)'); end; Any hints welcome, thanks in advance. Best regards, and have a Merry Christmas! MatthiasSolved2.6KViews0likes6CommentsRe: Script recording abort with access violation in tcHook.dll
Dan & Helen, thanks for your hints, however that so far did not fix the issue but changed the behaviour: when clicking open now, the application does not popup the error message from EurekaLog, instead silently closes as if I had clicked "Exit". I tried both 32bit Debug and Release versions, release including modifications by WinLicense (I suspect also problematic for TC as this heavily modifies the exe incl. vm code creation etc.). But even the clean debug-only shows the problem. As I didn't have much time for this yesterday and will not during the day today, I will try more this evening. If the issue persists I'll get in touch with Tech Support and provide a URL for the executable so behaviour can be verified. Thanks for your help! Matthias2.4KViews0likes1CommentScript recording abort with access violation in tcHook.dll
Hi everyone, I have an odd problem when recording a script test under Windows 10, TC 11.20, application developed in Delphi 10 Seattle incl. EurekaLog. When I click file -> open in my app, I run an "execute" on the Delphi standard file open dialog. When recording, the dialog does not pop up but I get an "access violation at address 0" in tcHook.dll (image attached). I close the error raised by EurekaLog, stop recording and close the app. The script created is as follows: procedure Test1; var proj_LFH : OleVariant; var dlgErrorOccurred : OleVariant; begin TestedApps.Proj_LFH.Run; proj_LFH := Aliases.Proj_LFH; proj_LFH.FORM_Main.Click(17, 41); proj_LFH.wnd32768.Click(48, 15); dlgErrorOccurred := proj_LFH.dlgErrorOccurred; dlgErrorOccurred.checkRestartApplication.ClickButton(cbUnchecked); dlgErrorOccurred.btnDontSend.ClickButton; end; So the last 3 lines contain the "issue section". Funny thing: when I run this again, the file open dialog pops up as expected, no access violation... So I can "bypass" the problem by dropping those lines and continue recording, but this is not really what it should be like. Anyone got an idea? Thanks in advance! MatthiasSolved2.5KViews0likes4Comments