The Message Box called here is not closing upon clicking "OK". Keeps popping up until I kill the task via Task Manager.
The runtime environment is WinCE 6.0.
Private Sub frmPAConsole_Activated(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Activated
strConfigFileName = "\Program Files\Alarm System\PASystem_AudioFilesAllocation.txt"
If Not IO.File.Exists(strConfigFileName) Then
MsgBox("Configuration file doesn't exist: \Program Files\Alarm System\PASystem_AudioFilesAllocation.txt")
Me.Close()
End If
Call LabelStopButton()
Call ReadConfigFile(strConfigFileName)
Call PopulateButtonsDescription()
End Sub
I tested a message box when just clicking a button - no problem. Also, the device Windows messages are closing normally.
Any ideas?
Thanks!
This seems like some sort of a bug.
Even when implementing the Error Message using a new dialog form - the stickiness of the message persisted ONLY for the IO.file.open error (regardless of whether it was raised by error handling or checked if file.exist).
The only workaround I managed to do is instead of having error messages pop up in new windows, I implemented a textbox on the main form itself, on the bottom, for error messages, and I control its text and visibility.
Thank you all for reading and thinking about this issue.
Related
I am automating a website. I am using SeleniumBasic in Excel VBA.
I have a simple Pop-Up, or Alert, with an OK button.
I cannot access the Pop_Up by using Inspect so I have no HTML to show.
When the Pop-Up occurs, I respond with Driver.SwitchToAlert.Accept. It goes away, as desired.
I don't know how to check programmatically if the Pop-Up is present.
If I assume that the Pop-Up may have occurred and use this code on a just-in-case basis, i.e. use the code without the Pop-Up existing, the program stops without any error message.
Is there a way to check if the Pop-Up window exists before I respond?
Well, I found the answer:
I got this code from someone who got it from someone else.
Private Function AlertIsPresent() As Boolean
'Returns true if an alert is present, false otherwise
Dim T As String
On Error Resume Next
T = Driver.Title 'This raises error 26 if an alert(pop-up) is displayed
AlertIsPresent = (26 = Err.Number)
End Function
If function returns 'true', use the Driver.SwitchToAlert.Accept to close it.
I would like to create/use toasters notifications on Excel. Because we already use MsgBox to notify the user that something happen.
But it make the script to stop (pause).
Have you any idea of how to do ?
On google there is "System Tray Notification" but it need a lot of code and this is a old method. Can't find if there is a new method.
For example, the plugin from SAP : "Analysis For Office" put notifications on Excel.
I looked into this once and almost gave up on it entirely until I found a rather 'cheaty' way of alerting users of info without suspending execution, that works on my users machines.
We run Windows 10 here and have SCCM installed for software distribution and updates. I've absolutely no idea if that's mandatory in Windows for updates or not, so I've no idea if this works for you.. but the following code works a treat here if you don't mind the notification resembling a Software Centre notification:
Sub Toastnote(ccmTitle, ccmText)
Shell "c:\windows\ccm\sctoastnotification.exe """ & ccmTitle & """ """ & ccmText & """ "
End Sub
You can call it with:
toastnote "title goes here","message goes here"
It creates a little pop-up that looks like this:
As I say, it's a bit of a cheat and might confuse users who regularly receive CCM notifications, but for my user-base that wasn't an issue.
Lastly, it's probably worth wrapping this in an IF statement that checks the .exe file exists - just a thought..
Using the Plugin "Analysis For Office" from SAP, you can define messages and add them to the standard SAP-AnalysisForOffice message dialog :
Dim lResult As Long
lResult= Application.Run("SAPAddMessage", "This is a new error message!", "ERROR")
The message 'This is a new error message' with severity Error is displayed in the message dialog.
It will do the same as the picture sent with my question.
Source
Details about SAPAddMessage
I had a similar requirement (mainly for debugging)
My solution was to pop up a small form with a single label control and unload it 4 seconds later. The form proeprties are set no not show modal etc.
in a VBA "Module"
Private mFrmToast As frmToast
Public Sub clearToast()
On Error Resume Next
If Not mFrmToast Is Nothing Then
mFrmToast.Hide
Unload mFrmToast
Set mFrmToast = Nothing
End If
End Sub
Public Sub showToast(message As String)
On Error GoTo er_clear_in_4
If mFrmToast Is Nothing Then
Set mFrmToast = New frmToast
End If
mFrmToast.message = message
If Not mFrmToast.Visible Then
Call mFrmToast.Show(False)
End If
er_clear_in_4:
Application.OnTime Now + TimeValue("00:00:04"), "clearToast"
End Sub
The form "code behind" module contained a sample write only property, "message".
Option Explicit
Public Property Let message(ByVal sMessage As String)
lblMessage.Caption = sMessage
End Property
The usage is simply
showToast("your message here")
I have a COM automation server hosted by a VB6 exe.
The COM API is used from Excel VBA:
Dim o as MyCOMAPI.MyCOMType
Set o = new MyCOMAPI.MyCOMType
o.DoSomething
When I create objects in VBA the exe is started along with COM automation and VBA can use the API.
But the exe is closed quickly and "randomly" by Excel, I guess when Excel decides it doesn't need the COM API anymore.
This behaviour is causing random errors.
The simple solution is to start the exe before running the VBA code ; in this case all is working fine as the exe won't stop running until closed by the user.
Have you some information/documentation about the way Excel VBA manages calls to hosted APIs?
Is there a way to avoid this behaviour and have the exe kept open until the VBA code decides to stop it?
This would be the default behavior for a COM automation server when the last object is dereferenced, meaning that the variable that points to the server is set to nothing.
Now, if your code looks something like this today:
Sub MyFunction()
...
Dim o as MyCOMAPI.MyCOMType
Set o = new MyCOMAPI.MyCOMType
o.DoSomething
End Sub
Then, the server life is connected to the life of the o variable. That variable gets set to nothing when the function is finished, and then the server will be shut down (unless there are other variables keeping it alive).
To make sure that your COM server is kept alive for a longer time, simply define the variable as a Public variable as in the sample below.
This sample will start and show Excel and keep it open until the ShutdownExcel function is called.
Public o As Excel.Application
Sub MakeSureExcelIsRunning()
If o Is Nothing Then
Set o = New Excel.Application
o.Visible = True
End If
End Sub
Sub ShutdownExcel()
Set o = Nothing
End Sub
From COM docs.
**Component Automation**
Shutting Down Objects
ActiveX objects must shut down in the following way:
If the object's application is visible, the object should shut down only in response to an explicit user command (for example, clicking Exit on the File menu) or the equivalent command from an ActiveX client.
If the object's application is not visible, the object should shut down only when the last external reference is gone.
If the object's application is visible and is controlled by an ActiveX client, it should become invisible when the user shuts it down (for example, clicking Exit on the File menu). This behavior allows the controller to continue to control the object. The controller should shut down only when the last external reference to the object has disappeared.
© Microsoft Corporation. All rights reserved.
When you write an COM server exe the first thing you do it take a reference to yourself when starting as a normal exe else the exe shuts down as soon as initialisation is over.
I'm trying to clean up my code on save using Resharper's Cleanup Code function. I made a macro that handles DocumentSaved events. The important parts:
Private Sub DocumentEvents_DocumentSaved(ByVal document As EnvDTE.Document) _
Handles DocumentEvents.DocumentSaved
...
DTE.ExecuteCommand("ReSharper_SilentCleanupCode")
document.Save()
End Sub
Every time I save, I get an exception message that says Error HRESULT E_FAIL has been returned from a call to a COM component. Any ideas?
Note: I see How can I configure ReSharper's code cleanup on save? and it won't work in my situation because I need to respond to the save event. Mapping a macro to CTRL+S isn't enough.
I think this is because when you call document.Save() it is recursing and saving again and then it falls over. Try this:
Private Sub DocumentEvents_DocumentSaved(ByVal Document As EnvDTE.Document) Handles DocumentEvents.DocumentSaved
Static currentDocument As EnvDTE.Document
If Not currentDocument Is Document Then
currentDocument = Document
DTE.Windows.Item(Document.Name).Activate()
DTE.ExecuteCommand("ReSharper_SilentCleanupCode")
DTE.ActiveDocument.Save()
End If
End Sub
This worked for me
Background: I am using OmniThreadLibrary to load batch mode ADO stored procedures in the background. I am doing some slightly dodgy stuff by swapping the connection after opening the SP but that seems to be quite reliable. I'm using PostMessage to send messages back to the calling form and that works in my test applications. Primoz' comms channels work for me, I'm using those for inter-thread comms but for our main application I'm trying to avoid that dependency by using standard PostMessage calls as we do elsewhere in the app.
Problem: Unfortunately when I put this into our main application the PostMessage calls in the thread start failing with 1400:invalid window handle.
I have liberally added extra PostMessage calls and logging code to try to locate the problem, but I'm out of ideas now. The code is boilerplate:
const WM_PW_ADLQUEUEEMPTY = WM_USER + 11;
...
if PostMessage (OwnerHandle, WM_PW_ADLPROGRESS, QueueID, 10) then
pwDebugLog ('TADLQueue.Run WM_PW_ADLPROGRESS send to ' + IntToHex (OwnerHandle, 8) + ' (IsWindow '+BoolToStr(IsWindow(OwnerHandle),true)+') OK for Queue ' + IntToStr (QueueID))
else
pwDebugLog ('TADLQueue.Run WM_PW_ADLPROGRESS send to ' + IntToHex (OwnerHandle, 8) + ' (IsWindow '+BoolToStr(IsWindow(OwnerHandle),true)+') failed for Queue ' + IntToStr (QueueID));
But the log for a series of calls is not very revealing to me. note that the four hex digits after the time is the thread id from GetCurrentThreadID.
15:41:53.221 1614 TpwAsyncDataLoader.RunQueue WM_PW_ADLPROGRESS send to 00A5110C (IsWindow True) OK for Queue -6
15:41:53.265 13B4 TADLQueue.Run WM_PW_ADLPROGRESS send to 00A5110C (IsWindow True) OK for Queue -6
15:41:53.554 13B4 TADLQueueManager.WriteSysErrorMessageToDatabase Postmessage 00A5110C (IsWindow False) failed with 1400 Invalid window handle
Can anyone shed some light on this? I'm confused at how a window handle can become invalid while I'm looking at it, but that's what it looks like to me.
The one thing I can think of is that the form I'm showing here isn't processing messages and I'm seeing a "message queue full" failure rather than the IsWindow(handle) failure that it looks like. How can I test for that?
There are cases where a handle gets recreated, most notably when you change window flags. This might be what's happening in your application.
All I found so far about recreating windows handle is this post from Allen Bauer but I'm certain reading a more detailed one written by Peter Below. Unfortunatly I can't seem to find that one.
Finally, you need to be aware of cases
where your handle may need to get
recreated. This can happen if the
surrounding form or the parent
component's handle goes through a
recreate process. Up until more recent
releases of Windows, the only way to
change some window flags was to
destroy the handle and recreate with
new flags in the CreateWindowEx()
call. There are many components that
still do this. You know if you're in a
recreate situation by checking
(csRecreating in ControlState).
Edit
Not actually the posts from Peter I had in mind but it might give you some fresh ideas.
The form will not have a handle until
you show it the first time (unless
something in the form load sequence
request the handle) but the handle is
not destroyed when you hide the form
and unless you do something that
forces the form to recreate the
handle, e.g. change its border style
or border icons, or call RecreateWnd
yourself the handle will stay the
same.
It may not be desirable but it cannot
be avoided, at least not the way
Delphi drag&dock is currently
implemented. When you dock the dragged
form to another form it becomes a
control (with WS_CHILD window style)
and that means that its window handle
has to be destroyed and recreated with
the new style. And destroying the
window handle of a container control
automatically destroys the handles for
all child controls as well.
and
There is also the fact that the forms
window handle is destroyed and
recreated when you assign to its
Parent property. This also destroys
and recreates the handles for all
controls on the form.
I had a similar issue (but in VC++2010), and I did not find the solution on any forum, so I post it here, hope this will help:
Issue:
Creating a thread,
Passing the HWnd handle
In the thread, PostMessage
throws a 1400 error (invalid handle), although the pointer was equal
with the handle as seen from UI thread (with GetSafeHWnd()).
Solution:
Do not pass the handle, but the parent CDialog(Ex) class
This class has a m_hWnd member that will do the job
Here is a (Cpp) example, sorry for the cast mess.
// In the worker thread
ThreadParam *threadParam = (ThreadParam*)param
// This is ugly because my pointer is a void *, to avoid one more forward declaration
CCoreGenDlg *dlg = static_cast<CCoreGenDlg *>(threadParam->ptr);
// Post
bool b = PostMessage(dlg->m_hWnd ,1221,0,(LPARAM)message);
Cheers'