I have a multi-form Windows mobile application that accesses the barcode scanner of the MC75 using the EMDK (version 2.6). I access the barcode scanner using a Singleton. When the application starts I call barcodereader.Actions.Enable() and when the application exits I call `barcodereader.Actions.Disable()'. Basically I've used the EMDK samples as a guide to get the scanner working.
While the application is running I add the event handler to the barcode reader `readNotify' on the form activation event and remove the event handler when the form activates. I have put code in to check that this is happening correctly and added a check to ensure no existing event handlers are present before a new one is added.
The application works fine but for some reason the barcode scanner suddenly cuts out and will not work when the trigger button is pressed. This always seems to happen in the same place (after around 20 odd scans spread across the three forms). No error is caught and the scanner light fails to come on. I have a set number of scans to do and the scanning stops on a form where I've done a successful scan seconds earlier. I can do more than 20 scans on a single form but I only seem to get the issue when doing scanning on different forms.
If I restart the application the scanner works again. The datawedge software is installed but is not used.
I have seen this issue during my research here, but my issue does not seem to be intermittent.
I saw a note on the Symbol support site stating it was not desirable to repeatedly call `.Actions.Enable' and '.Actions.Disable' when moving between forms and I don't do this.
I'm at a loss as to what to check in the application. Any ideas?
Details - using Windows Visual Studio 2008, device is running Windows Mobile 6.5 Professional, EMDK version 2.6, application written in C#.
I had this exact same issue on an MC70 device. Unfortunately it was at a previous employer so I no longer have the source code to look back on. I do remember having to create a somewhat ugly workaround to get it working.
I know that I ended up declaring/instantiating the barcodereader object inside of the parent form (so no need for the singleton class). Then every time I instantiated a child form, I passed either the parent form object or the barcodereader object BY REFERENCE into the child form. Then I was able to access it from the child form repeatedly without it crashing/locking up. I know that is a pretty vague description, but it's been a couple of years since I worked on that code. Hope this helps.
I knew this problem years ago!. The solution to that is: DON'T disable the barcode reader when doing form navigation (Keep it always Active ). It works perfectly for me (I did MC9062 6 years ago and now MC75A device). Just put some logic to tell your program to handle scanned data differently under different form.
Yes, it is important to use reader object as "Singleton".
Related
During my process there is a drop-down html element that I have spied and set correctly. I run through the Object and Process studio without any issues. Once the same process is ran through the Control Room the element throws and error that it cannot be found.
I have tried multiple different configurations without any luck and the element is still found without issue when ran manually. I even checked by signing into the VM having it error and on the second retry had the VM up; at this stage the element was found without issue. It seems to only be when the bot is running and the screen is not up. No other elements give this issue and the next step is the same dropdown, but for a stop time not start.
Any help would be appreciated!
I have added pics of the STARTSPIED - START and ENDSPIED - END spied configs,the Navigation Stage, and the process correctly running in the Object Studio OB Studio correct.
Thank you!
For the person who down-voted this item...Configs here are my two days of config changes and research that I tried on my own before asking for help. This is my 5th automation that I have put into deployment without help, so thank you for down-voting someone trying to get help where they are stuck.
Your problem is most likely connected with the fact that processes run in the control room are executed much faster than in studio and your webpage might not be loaded on time (that would explain why it works after retry).
Best practice approach would be to add a dynamic wait stage after attach and use “Parent Document Loaded” option on the element you want to interact with. It will wait for the page to be loaded and then check exist for the element. I would also suggest splitting your action into two, first to set start date and second for end date.
Our legacy MDI desktop application uses the /dde switch in the association. When opening a file associated with it, and the application has not yet started up, Explorer pops up the following error:
There was a problem sending the command to the program.
The registry looks something like this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document]
#="App File"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\DefaultIcon]
#="d:\\Program Files (x86)\\MyApp\\version\\app.exe,1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open\command]
#="\"C:\\Program Files\\App\\app.exe\" /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open\ddeexec]
#="[open(\"%1\")]"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print\command]
#="C:\\Program Files\\App\\app.exe /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print\ddeexec]
#="[print(\"%1\")]"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto\command]
#="C:\\Program Files\\App\\app.exe /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto\ddeexec]
#="[printto(\"%1\",\"%2\",\"%3\",\"%4\")]"
Just to be clear, I just took these entries from the registry. I'm not well versed in what they do, but I can hazard a guess that they link the verbs to actions by way of the DDE interface.
Note that if the application has already started up, the document opens up fine in that instance. This is only an issue if the application hasn't started up and must execute a new instance of the application.
So, what is happening is that the associated file is opened through Explorer by double clicking on it, and the associated application is executed. Explorer would then pop up that message and our application would do nothing. Double clicking on the file a second time would then open the document.
We've had this issue previously, but we just decided to ignore it for a few years as no one really knew what it was and we had other priorities at the time. Our workaround was to tell the user to change the /dde to "%1". Yeah, lame, but it worked well enough. One issue with doing that though, was that it would execute a new instance of the application, regardless if the application was already running or not.
Anyways, this issue is now starting to become an actual problem and needs to be fixed. One of our developers is saying that the DDE system is antiquated and we should try writing a COM component that will redirect to our application like Visual Studio does as debugging this issue could take a while. I've not verified that yet, nor researched how much effort that would be. However, either may be resource intensive, either on the debugging or the research side, so I'm trying to do some preliminary research to see what I can dig up and determine which is the better approach.
Stepping in the code, I was able to determine that it gets to a ::SetWindowPlacement() call and stepping over that will cause the error message box to pop up (if Explorer hasn't timed out first). As it is a WINAPI, I cannot step into that function to see what it is doing.
The application is written mostly in VC/VC++ using MFC/API and other libraries.
So my question is, does anyone know why this is happening and how it can be fixed?
Edit
Some additional information:
I was able to intercept all of the SendMessage()/PostMessage()/DispatchMessage() function calls non-destructively, which will log all of the messages. This was achieved by using MS Detours 3.0.
What I am seeing is that there are 4 SendMessage calls with a WM_COPYDATA message which appears to be coming out of shell32.dll. However, it doesn't appear to be the messages that are at fault though.
Putting a __debugbreak() when it detects the WM_COPYDATA message results in no error until a few steps beyond. How far depends on if I step or if I put a breakpoint and run the code to somewhere beyond where I thought I was getting the error. Using DebugBreak() seems to slow down the debugger to the point where I can't step without the error showing up.
What I can't understand is that there doesn't appear to be any rhyme or reason as to what is triggering the error message to pop up. I doesn't appear to be a timeout as the timeout appears to be long until I start stepping in the code, and sometimes no messages are being Sent/Posted by the code. So there's no WM_DDE_ACK (or any message for that matter) being sent back to the Explorer window that has initiated this. This is very frustrating.
To further complicate things, if I use the intrinsic __debugbreak() call and I have a breakpoint somewhere else in the code, it sometimes can stop at that breakpoint rather than stopping at the __debugbreak(). And sometimes, when I run the code immediately when I get control of the debugger, it will sometimes result in a second break, as if it hit another __debugbreak(). What's that all about? Inconsistent debugging is certainly making this issue even harder to track down. >:(
This DDE stuff is still the in use for MDI interfaces. So if one EXE opens different files.
If you can launch you application multiple times and this is OK, for the customer, switching the entries in the registry to the normal place holders from the SDI is OK too.
Usually this message is shown from the explorer, if the EXE doesn't get ready in a specific time to accept the DDE commands.
So the main question for you is: What is changed or so slow in the application that the DDE messages are not retrieved.
On case would be if it takes a real long time until the message loop starts. A running message loop for the main window is required for DDE support.
SetWindowPos istself will not be the problem, but it might cause hundreds of messages (WM_SIZE, ...) to be fired to your application, and every handler in your application here might be the problem.
Just place a little timer inside the application in front of the SetWindowPos and check how long it takes to return...
Check how long the app takes, until InitInstance is exited with TRUE. After InitInstance exits CWinApp::Run starts and the message loop starts.
I've run into the same problem.
My solution was to add the ../ddeexec/* section in the registry on application startup and then remove them on application exit.
Not a very nice solution but it is easy to do, and it works.
Background:
I am in the process of designing an application that will allow items to be dragged to it and will invoke some long running processes on them. The items will normally be dragged in from the filesystem and from Outlook. My concern is with the latter.
How can I hook into Outlook to find out if a message (or several) has been dragged out of it and on to my application and what the message ID is/are?
I understand that the Outlook object model does not have such drag/drop events and one solution is to listen to the Windows messages - this is not feasible in the team, as our combined Interop knowledge is not great.
We will be using C# 4.0 in Visual Studio 2010 for developing this application.
Even this is an old question, there is actually a way. It's undocumented, but I was able to reverse engineer this at least half way. I'm not sure though if the "Selection"-method is still cleaner, but I prefer to read the data directly.
A sample and the docs for this can be found here:
https://github.com/yasoonOfficial/outlook-dndprotocol
You cannot get access to the MailItem.EntryID directly from Outlook via the generic IDataObject drag-n-drop interface. If you just want to access the MSG data, then you can use this CodeProject example. Once an MSG is copied to disk (or clipboard, drag-n-dropped, etc.), it loses any reference to an EntryID.
The only way I know of to get access to the EntryID is by using VSTO and using the ActiveExplorer().Selection to see which items are selected at the time of the drop action. Here is an example of accessing the Body of a selected message during a drag-n-drop command. You should be able to find numerous examples once you see the general pattern being used.
I posted a few threads the other day on the Watir General Google Group, one of which detailed my difficulty using set_no_wait on a validated text field (link below); and was asked by Jarmo Pertman whether it was in a frame. It is, and this concerns me a little; as sadly the site I'm testing is heavily frame-centric, with no immediate plans to modernise.
I recently migrated from an ageing Ruby1.8.6/Watir1.6.2 test environment to Ruby1.8.7-334/Watir2.0.1, and am now noticing more methods that are no longer working for me in frames. For instance, click_no_wait on a button that presents a new window works perfectly fine in my old environment, but not in my new one.
This is a question to the Watir developer group. Are no_wait methods known to be failing in frames in Watuir 2.0.1? If so, are they being addressed? If they're not, then I'll be forced to revert back to an archiac version of Ruby and Watir. For many reasons, I don't want to do this.
(Environment: Ruby 1.8.7-334. Watir 2.0.1. XP Pro. IE8)
http://groups.google.com/group/watir-general/browse_thread/thread/85a1a872d1e054dc
from the comments:
Something occured to me last night; I had installed DevKit, which was required to get the FastDebugger working in Netbeans 7.0.1. After completely reinstalling Ruby1.8.7/Watir2.0.1 without DevKit, click_no_wait and set_no_wait now seems to be working for me. It means I'll have to use something else other than Netbeans to run my scripts, but at least my scripts work again. (github.com/oneclick/rubyinstaller/wiki/Development-Kit) I hope this info helps someone else. GJHmf – GJHmf Sep 1 at 10:19
(inserting this answer because:
the OP was requested to but had not done so within a months time.
it removes this from the list of 'un-answered' watir related
questions
)
I inherited an very old application that I am in the process of updating it (I know, we should have rewrote it in VS 2008, but we purchased a company, which is how I was stuck with the relic). Using UpdateData(TRUE) to retrieve the changes made in the dialog controls, nothing is being updated. I have an edit control, with an integer variable, and an edit control with a string variable, assigned using the class wizard. Upon pressing the OK button, the UpdateData(TRUE) is executed to retrieve the new values from the disalog.
I seem to remember having a similar problem back when VS C++ 6.0 first came out, but have not used it since VS 2003 and C# became prevalent.
Thanks for any help in advance!
Bill
Check the DoDataExchange() method. It should have the logic for writing data to or reading it from the controls. If the programmers used the default implementastion, then there will be a DDX_... macro for each control that is being read/written. Just look at any other MFC dialogs (in your code or google) to see how the DDX commands should be written if they are missing.
Alternatively, if it's only 1 or 2 values you can easily just get the control and read it directly if you don't mind doing validation etc yourself. Get the ID of the control from the form designer and use something along the lines of:
CEditWnd *pWnd = GetDlgItem(ID_THECONTROL);
CString newValue = pWnd->GetWindowText();
...
You'll need to look at the content of the DoDataExchange method and see what it is doing. There is not sufficient information here to tell what could be going wrong other than that.