I'm new at AT commands, and I'm having an issue when I try to receive a SMS in my SIM card.
It's a D-link DWM-157 (I guess that's it).
How I'm doing:
AT
OK
AT+CMGF=1
OK
AT+CPMS?
+CPMS: "SM", 0, 0, "SM", 0, 0, "SM", 0, 0
and then it returns the SM as 0,0, as if the SIM card had no max SMS storage capacity.
I tried plugging off and on again the modem and sometimes it works just fine, but when I reset it again, the problem comes back.
Can you guys help me understanding what's going on?
Related
I can not configure to receive events about changing the size of the terminal using ncurses QNX Momentics.
I am using Putyy as a terminal and data is transmitted through the COM port.
My question is how to realize the reception of screen change events when using a remote terminal?
FILE* fcons = fopen("/dev/ser1", "r+");
SCREEN* term = newterm("xterm-r5", fcons, fcons);
int y = 0, x = 0;
//if(y < 24 || x < 80)
// resizeterm(24, 80);
flushinp();
main_scr = newwin(24, 80, 0, 0);
head_scr = subwin(main_scr, 3, 80, 0, 0);
prompt_scr = subwin(main_scr, 1, 9, 3, 2);
cursor_scr = newwin(1, 60, 3, 6);
output_scr = subwin(main_scr, 18, 76, 5, 2);
keypad(cursor_scr, TRUE);
int f = mousemask(ALL_MOUSE_EVENTS, NULL);
chtype temp_ch = 0;
while(KEY_RESIZE == temp_ch)
temp_ch = wgetch(cursor_scr);
return 0;
A plain serial-port connection like that won't send a SIGWINCH. In other configurations, e.g., telnet, that's done as a result of NAWS (negotiations about window size--I dont't see a duplicate). Your application could poll for this by doing what the resize program does, plus a little more, e.g.,
save the cursor-position
move the cursor to a very-far-off lower-right corner
ask the terminal where the cursor really is
wait for the response, to get the actual screensize
set the terminal's screensize using a system call
restore the cursor position
send a SIGWINCH to yourself
Unlike resize, that would be done inside your program, so it would have to save/restore the cursor position (to avoid confusing ncurses). Keep in mind that ncurses has set the terminal to raw mode, so that part of the initialization would not be needed.
I have updated my xcode to 8.0 and trying to run a sample demo app. i am getting the messages in log file like that 3 or 4 times . whats happening ??
2016-09-20 21:09:39.807151 demo[34599:1708960] subsystem:
com.apple.BackBoardServices.fence, category: App, enable_level: 1,
persist_level: 0, default_ttl: 0, info_ttl: 0, debug_ttl: 0,
generate_symptoms: 0, enable_oversize: 0, privacy_setting: 0,
enable_private_data: 0
These are OS Activity logs. You can disable this as so:
Goto Project> Schemes > Edit Scheme
In the window select Run
Add the the environment variable as follows
When you create a kqueue with kqueue() you get back a file descriptor. But it appears that this file descriptor cannot be meaningfully polled with select(). I understand that the standard way to poll/read from a kqueue() is with kevent(...) but I'm trying to integrate with some legacy code that polls file descriptors using select().
The goal here was to be able to fire a "user event" that can be detected by this select-based polling mechanism (even if the event eventually needs to be "consumed" using kevent() later). This looked like the kind of thing EVFILT_USER was born to do, but a quick experiment indicates that select() doesn't report the kqueue's fd as being ready to read when an event is added (and triggered) in the kqueue, it just times out (or blocks forever). (But an equivalent kevent() call does see/return the event.)
Am I doing something wrong? Or is it just not possible to poll a kqueue's fd with select()?
The paper, describing kqueue/kevent says (sect 6.5):
Since an ordinary file descriptor references the kqueue, it can take
part in any operations that normally can per - formed on a descriptor.
The application may select(), poll(), close(), or even create a kevent
referencing a kqueue;
This is indeed the case for FreeBSD, i've checked this with following code:
struct kevent e;
fd_set fdset;
int kq=kqueue();
EV_SET(&e, 1, EVFILT_USER, EV_ADD, 0, 0, NULL);
kevent(kq, &e, 1, 0, 0, 0); // register USER event filter
EV_SET(&e, 1, EVFILT_USER, EV_ADD, NOTE_TRIGGER, 0, NULL);
kevent(kq, &e, 1, 0, 0, 0); // trigger USER event
FD_ZERO(&fdset);
FD_SET(kq,&fdset);
select(FD_SETSIZE,&fdset, 0, 0, 0); // wait for activity on kq
int res = kevent(kq, 0, 0, &e, 1, 0); // get the event
So have seen a ton of people with the same issue's but no answers. My SendMessage pop's up the "Video Source" dialog box on a windows 7 laptop with one camera. I have Cyber Link YouCam installed.
If I uninstall Cyber Link YouCam the "Video Source" dialog goes away. It appears to be the OS is acting as though YouCam is a second driver for the same device. My question is how do I stop the dialog box for "Video Source" from appearing? Once I choose an option in the dialog I don't get the dialog box (until I restart the application) so there must be a setting somewhere being set.
Though debugging found this bit of code (see whole section below) is the one that seems to be the one that calls the dialog box - SendMessage (deviceHandle, WM_CAP_CONNECT, deviceno, ((IntPtr) 0).ToInt32 ())
public void StartWebCam (int height, int width, int handleofthepicturebox, int deviceno)
{
string deviceIndex = "" + deviceno;
deviceHandle = capCreateCaptureWindowA (ref deviceIndex, WS_VISIBLE | WS_CHILD, 0, 0, width, height, handleofthepicturebox, 0);
if (SendMessage (deviceHandle, WM_CAP_CONNECT, deviceno, ((IntPtr) 0).ToInt32 ()) > 0)
{
SendMessage (deviceHandle, WM_CAP_SET_SCALE, -1, 0);
SendMessage (deviceHandle, WM_CAP_SET_PREVIEWRATE, 0x42, 0);
SendMessage (deviceHandle, WM_CAP_SET_PREVIEW, -1, 0);
}
else
{
// nothing failed maybe some clean up needed
}
}
So again the question is - how do I stop the dialog box for "Video Source" from appearing?
I developed a form to display two live captures with avicap32 on Windows XP. There is a chance the fix I found in my case also applies to yours.
In the case of avicap, it is possible to programmatically manage your webcams, and all that is registry-based. Here is the thread I found to guide me and achieve what I wanted.
In this thread, the role of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo\MSVideo.VFWWDM\DevicePath registry key is highlighted for the selection of the active webcam.
And here is maybe a helpful piece of info: I had to set the value in lowercase to avoid the Video Source dialog popping up.
I determined it by monitoring the registry key before and after the call to SendMessage with WM_CAP_CONNECT.
To the best of my knowledge (and googling), nobody else has offered a fix, so even though I might be answering a little late, it would be great if you could tell us whether it worked for you as well.
Finally I Found a solution for this.
The problem happens in Windows 7 / 8
First you need this API function
Private Declare Function GetTickCount Lib "kernel32" () As Long
Then... after you call capCreateCaptureWindowA() you have to wait 1 second processing events, (note: sleep don't work the same)
IniTime = GetTickCount()
While GetTickCount() < (IniTime + 1000)
DoEvents
Wend
then you call WM_CAP_DRIVER_CONNECT (maybe a couple of times).. and THAT's IT ... no more video source dialog
With this solution it works perfect. The GetTickCount() waiting for events worked along with calling the function until it returned true.
Private Sub PreviewVideo(ByVal pbCtrl As PictureBox)
hWnd = capCreateCaptureWindowA(VideoSource, WS_VISIBLE Or WS_CHILD, 0, 0, 0,
0, pbCtrl.Handle.ToInt64, 0)
Dim IniTime As Long = GetTickCount()
While GetTickCount() < (IniTime + 1000)
Application.DoEvents()
End While
Dim OKAnswer As Boolean = False
For xretries As Integer = 1 To 10
' I'll give you Only 10 tries to connect, otherwise I AM LEAVING MICROSOFT!
OKAnswer = SendMessage(hWnd, WM_CAP_DRIVER_CONNECT, VideoSource, 0)
If OKAnswer Then
Exit For
End If
Next
If okanswer Then
SendMessage(hWnd, WM_CAP_SET_SCALE, True, 0)
SendMessage(hWnd, WM_CAP_SET_PREVIEWRATE, 30, 0)
SendMessage(hWnd, WM_CAP_SET_PREVIEW, True, 0)
SetWindowPos(hWnd, HWND_BOTTOM, 0, 0, pbCtrl.Width, pbCtrl.Height, SWP_NOMOVE Or SWP_NOZORDER)
Else
DestroyWindow(hWnd)
End If
End Sub
I had the same issue. Make sure you call capDriverDisconnect once you no longer need the webcam. Note that I'm using Logitech C110, but I suppose it should work in your case too.
Came over here searching for a solution for the "WM_CAP_DRIVER_CONNECT" and "Video Setup" dialog popup Error.
FOUND the solution:
It's a driver problem. Use the OEM's driver, because the Generic Microsoft Drivers are NOT working for your camera.
Use www.astra32.com to find out the USB camera's device info: Manufacturer or Model; then google for the correct drivers.
Good Luck!
in my application I am entering a loop of unknown number of elements,
so I am showing a progress bar to inform that application is running,
and this code works FINE, progres bar is refreshing independly:
do
{
...
SendMessage(hPBLoading, PBM_STEPIT, 0, 0);
...
} while(true);
but unfortunately the rest of window doesn't refresh (which is obvious due to the loop)
and in Windows 7 after a few seconds Windows treat my app like it break down, and it back and refresh after ending the loop,
so I figured out that I need to dispatch the message queue and I changed my code to this:
do
{
...
SendMessage(hPBLoading, PBM_STEPIT, 0, 0);
...
us_tmpBreakCounter++;
...
if (us_tmpBreakCounter >= 10)
{
us_tmpBreakCounter = 0;
UpdateSomeOtherElementsinWindow();
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) == TRUE)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
} while(true);
It works fine, the applcation is updated and refreshed after ex. 10 counts so its never break down,
but unfortunately another problem occured, now the PROGRESS BAR doesn't redraw fully - the beveled frame dissapears after a few seconds, check this image below:
http://mstanisz.website.pl/temp/progressbar_01.jpg
Thanks For Your Help!
m.
Seems like you're using a GUI thread to do some long task. That's not a good practice. When you want to perform long tasks, use a worker thread for that, and let the GUI thread handle the GUI while the worker works. You'll have to do some extra work taking care of synchronization between the two threads (stop the worker if the GUI is closed, avoid starting a task before the current one has ended and so on), but that's the way it works.