I've run into an issue with the automation of one of my Photoshop scripts where it can be completely halted by an error in a supporting action set. The script does about 99% of the work, but the remaining 1% has to be done in an action due to the work being done (the work is NOT scriptable, or at least not efficient in the least to put to script). The problem I'm running into is that, if there is an error in the layer name in the action, Photoshop pops up an alert about the issue, halting the whole process until I click the "Ok" button on said alert.
Is there any way to catch these errors (a simple try/catch on the action activation code doesn't work), or at least suppress the errors so they don't halt the entire process? Thanks in advance for any help!
Edit: Correction on the error type; it's not an "Ok" alert, it's a "Continue/Stop" alert. The message accompanying it is "The object "layer "layerName"" is not currently available". This happens if the person creating the action failed to rename the layer before performing their work on it and halts the entire automation process until I click continue or stop.
You should convert the action to a script using ActionToJavascript.jsx. After which you can then modify the script to look out for errors - such as you mentioned with the layers not being named correctly.
Related
I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.
all. Today I upgraded my gDEBugger (though I don't think it involves gDEBugger) to the latest version but problem occurs. When I tried to open gDEBugger, an alert window named "wxWidgets Debug Alert" pop-up, reporting that "....\src\common\xpmdecod.cpp(822):assert "i==colors_cnt" failed in wxXPMDecoder::ReadData(). Call stack: [00]wxConsole....balabala....", like follows.
All these words seem just like warnings and didn't affect the following work, however I am wondering why this problem occurs? What's the root cause? I am not familiar with wxWidgets and hopes those guru on it can help me resolve it.
You've got a malformed XPM. As XPMs are typically embedded into the program itself, this is not supposed to happen, look at the XPMs used by gdPerformanceCountersDialog::createAndLoadImageList() to check this.
P.S. Next time you could just press Ctrl+C to copy the message box contents to clipboard as text instead of pasting in an image.
I was working on a Windows app today, when my errors were no longer being displayed as they usually would. Instead, the debugger just jumps out of the method. The output window makes a note of the exception, but the usual popup trace does not appear.
It works in other projects, and I have put Dim i as Integer = "A" as my first line to try and raise an error, but it just exits the sub on that line.
Any ideas how I get it back?
There is a bug in the interaction between the debugger and the 64-bit version of Windows 7 that strikes in the Load event. An exception is trapped and swallowed by Windows, the debugger never gets a chance to detect that it was unhandled. The only thing you'll see is a "first chance" notification in the Output window. The Load event handler will immediately terminate and your program keeps running as though nothing happened, assuming that it didn't bypass a critical piece of initialization code. This bug has been around for a long time and is well known to Microsoft, apparently it is difficult to fix.
You can work around this bug with Project + Properties, Compile tab, scroll down, Advanced Compile Options button. Change the Target CPU setting to "AnyCPU". Another way to trap it is with Debug + Exceptions, tick the Thrown checkbox on CLR Exceptions. Yet another workaround is to put initialization code in the constructor instead of OnLoad() or the Load event. You only really need Load when you need to know the actual size of the window.
This bug will only strike when you debug. It won't happen on your user's machine.
UPDATE: I expanded a great deal on this mishap in this post.
Under the Debug->Exceptions check that the Common Language Runtime exceptions are checked.
Has your .suo file been deleted by any chance (this is the file that stores your personal state of the solution, your settings, what is expanded / collapsed). You will only really spot this if you suddenly noticed that you had to hit "collapse all" because it had forgotten, it will recreate this when you open the solution, but will do it with default settings.
If so, hit CTRL + ALT + E and re-tick the break on exceptions tick boxes for CLR exceptions.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?