I just upgraded to Xcode 8 and upon building and running my project an enormous amount of information is being printed to the Debug Area.
Here is a sample:
016-09-14 08:37:54.394736 SmartTapp[8645:112431] subsystem: com.apple.network, category: , enable_level: 0, persist_level: 0, default_ttl: 0, info_ttl: 0, debug_ttl: 0, generate_symptoms: 0, enable_oversize: 0, privacy_setting: 2, enable_private_data: 0
2016-09-14 08:37:54.395777 SmartTapp[8645:112431] [] tcp_connection_create_with_endpoint_and_parameters 1 www.smarttapp.com 80
2016-09-14 08:37:54.397472 SmartTapp[8645:112431] [] tcp_connection_start 1 starting
How do I turn this off?
I have already tried the suggestion offered here and it didn't work.Hide strange unwanted Xcode 8 logs
Open:
=> Product
=> Scheme
=> Edit Scheme
=> Select "Run"
=> Second Tab "Argument"
=> Inside Environment Variables press + button
=> add Name = OS_ACTIVITY_MODE & set the Value to disable
Press Close button
And you are done.
Related
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
Consider that I have the handle ($browser_handle) of a web browser window ('firefox') available in my AutoIt script.
I would like perform some keystrokes after I know that the firefox browser window is open and visible on my display so that I can bring it to focus using -
WinActivate($browser_handle)
or
WinWaitActive($browser_handle)
To make sure that the window is visible before I try to bring it into focus I have a while loop which waits till the state of the window handle is visible (2).
While (Not BitAND(WinGetState($browser_handle), 2)) WEnd //until window visible
If I use a Sleep(5000) function before the while loop then I do not face any issues.
If I do not use an arbitrary Sleep function in my script, the Whileloop condition never becomes true and turns into an infinite loop.
When I tried to check what the return value of WinGetState($browser_handle) is when there is no Sleep function,
It remains 5 even if the browser is visible and becomes 0 after the browser window is closed.
I'm unable to understand why the WinGetStatereturn value never becomes 2(visible) even if the browser is visible when there is no Sleep function.
This is a test code which can reproduce the issue -
#include <Constants.au3>
Local $browser_name = 'C:\Program Files (x86)\Internet Explorer\iexplore.exe'
Run($browser_name)
ProcessWait('iexplore.exe')
Local $browsers = ProcessList('iexplore.exe')
Local $pid = $browsers[1][1];
_WinActiveByPID($pid)
Local $sText = WinGetTitle("[ACTIVE]")
; Display the window title.
MsgBox($MB_SYSTEMMODAL, "", $sText)
Func _WinActiveByPID($pid) ;False to WinActivate, True to just see if it's active
Local $aWL = WinList()
For $iCC = 1 To $aWL[0][0]
If ($aWL[$iCC][0] <> '') And _
(WinGetProcess($aWL[$iCC][1]) = $pid) Then
While (Not BitAND(WinGetState($aWL[$iCC][1]), 2))
MsgBox($MB_SYSTEMMODAL, "", WinGetState($aWL[$iCC][1]))
WEnd
WinWait($aWL[$iCC][1])
WinActivate($aWL[$iCC][1])
WinWaitActive($aWL[$iCC][1])
Return 1
EndIf
Next
Return SetError(2, 0, 0)
EndFunc
Note:
WinWait does not work in this situation, If you see the example in the link there is a Sleep after WinWait, this function returns even if the window is hidden.
The browser window in my original script is not launched using Run, it is a Java program which opens the browser. I know that the Run method returns the PID of the browser which I can use to resolve this issue but since it starts from Java I have to use ProcessList to obtain the PID of the browser.
Please let me know how I can get this to work.
Thanks
You got thing too complicated for no reason there. Let me show you.
Local $browser_name = 'C:\Program Files (x86)\Internet Explorer\iexplore.exe'
Run($browser_name)
ProcessWait('iexplore.exe')
Sleep(500) ; because ProcessWait will exit when the process is created not when the window is visible. If your computer is slow you will have an problem
Local $BrowsersHWND = WinList()
Local $hBrowserHandle[2]
For $i = 0 To $BrowsersHWND[0][0] -1
If StringInStr($BrowsersHWND[$i][0], "Internet Explorer") Then
$hBrowserHandle[0] = $BrowsersHWND[$i][0] ;title
$hBrowserHandle[1] = $BrowsersHWND[$i][1] ;handle
ExitLoop
EndIf
Next
If $hBrowserHandle[0] = "" Or $hBrowserHandle[1] = "" Then Exit MsgBox(0, 0, "Internet Explorer not found")
Local $hState = WinGetState($hBrowserHandle[0])
Local $sVisibleStates[24] = [2, 3, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 34, 35, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47] ;visible states
Local $hCheck = False
For $j = 0 To UBound($sVisibleStates) -1
If $hState = $sVisibleStates[$j] Then
ConsoleWrite("Window state(visisble): " & $hState & #LF)
$hCheck = True
ExitLoop
EndIf
Next
If $hCheck = False Then
ConsoleWrite("Activating: " & $hBrowserHandle[0] & #LF)
WinActivate($hBrowserHandle[0])
EndIf
I have added all the cases of states where your window would be visible.
WinWait will not activate any window and I recommend you never use it. It could freeze a script for ever without reason. I will not explain why because it would take pages but avoid it. Also avoid using WinWaitActive. For similar reasons.
You have too many issues in your code that's why I completely changed it. Not worth explaining it.
I think the problem is not necessarily with the code, but possibly with the logic. I could be way off base here, but maybe we should not be looking for a state of 2, but something closer to 15.
A sample with notepad:
$WIN_STATE_EXISTS (1) = Window exists
$WIN_STATE_VISIBLE (2) = Window is visible
$WIN_STATE_ENABLED (4) = Window is enabled
$WIN_STATE_ACTIVE (8) = Window is active
A window that is active (8), enabled (4), visible(2), and exists(1) will have a windows state of 15.
; Look for notepad and display WindowState number
if WinExists("[Class:Notepad]") Then
MsgBox($MB_SYSTEMMODAL, "", "Found")
WinActivate("[Class:Notepad]")
$WinState = WinGetState("[Class:Notepad]")
MsgBox($MB_SYSTEMMODAL, "", $WinState)
EndIf
I have the following rule in my dwm config file:
{ "Quodlibet", NULL, NULL, 1 << 4, False, -1 },
If instructs dwm to always launch an app titled Quodlibet on the fifth tag, a tag being the equivalent of a virtual desktop.
What if I wanted to have this app launched on a secondary screen?
The last element of the array determines which screen is used. Now, number the windows such the the primary monitor (the one sitting on the left) is 0. In effect, the line above would then be:
{ "Quodlibet", NULL, NULL, 1 << 4, False, 1 },
How can I update this progress bar in win32api? You can find the full code here Code is here
hProgress=CreateWindowEx(0, PROGRESS_CLASS, NULL,
WS_CHILD | WS_VISIBLE,
20, 20, 260, 17,
hwnd, NULL, g_hInst, NULL);
The message you are looking for is PBM_SETPOS. The usage of this depends on what the range is currently set to (defaults from 0-100). For example, assuming the default range, setting the position to halfway would be done as so:
SendMessage(hProgress, PBM_SETPOS, 50, 0);
Alternatively, the progress bar can be incremented in steps through PBM_STEPIT. The usage of this depends on what the step increment is (default to 10). For example, assuming the default range and initial position of the progress bar, stepping the position to 10 would be done as so:
SendMessage(hProgress, PBM_STEPIT, 0, 0);
Assuming you have initialised common controls :
INITCOMMONCONTROLSEX InitCtrlEx;
InitCtrlEx.dwSize = sizeof(INITCOMMONCONTROLSEX);
InitCtrlEx.dwICC = ICC_PROGRESS_CLASS;
InitCommonControlsEx(&InitCtrlEx);
Set the range:
SendMessage(hProgress, PBM_SETRANGE, 0, MAKELPARAM(min, max));
Set the position:
SendMessage(hProgress,PBM_SETPOS,pos,0);
See: MSDN docs
You could use the PMB_STEPIT message to move the current position based on the step size:
int max_range = 1000;
// set range of progress bar
SendMessage(hProgress, PBM_SETRANGE, 0, MAKELPARAM(0, max_range));
// set the step size
SendMessage(hProgress, PBM_SETSTEP, (WPARAM) 1, 0);
// increment by step size
SendMessage(hProgress, PBM_STEPIT, 0, 0);
Here is a good example How to Use Progress Bar Controls
In addition to updating the progress in the progress bar, you must also give it a chance to repaint. Usually you're showing a progress bar because you're busy working, and so the normal message loop isn't running and no WM_PAINT messages are generated. You can call UpdateWindow to repaint the window immediately.
I am trying to see if I can make my own simulation loop inside Manipulate as I am not happy with either the Trigger control or using Tasks (both have problems and limitations for what I'd like to do).
So, I was trying to see if I can make my own control loop, this way I have better control of things, where by clicking on a 'run' button, simulation loop will start until a 'stop' button is clicked.
A basic problem is that Manipulate times out after 5 seconds even though I am using SynchronousUpdating -> False. i.e. when I click the 'run' button, I start a loop (with some Pause[] in it of course), and will then update something in the loop. This works fine, but after 5 seconds, the loop stops on its own, since Manipulate decided to time out.
I might be misunderstanding something basic here. I show below simple example:
Manipulate[
Dynamic[Refresh[Text#x,TrackedSymbols->{x}]],
{{x,0},ControlType->None},
{{running,True},ControlType->None},
Button[Text["play"],
{
running=True,
While[running,
x+=1;
FinishDynamic[];
Pause[0.1]
]
}],
Button[Text["stop"],
running=False
],
TrackedSymbols->{None},
SynchronousUpdating->False,
SynchronousInitialization->False
]
When running the above, it always stops around count 58 or so, which is about 5 seconds, the time-out value for Manipulate
Outside Manipulate, it works ok as expected:
x = 0;
Dynamic[Refresh[x, UpdateInterval -> 0.001]]
Do[
(
x += 1;
FinishDynamic[];
Print[x];
Pause[0.01]
), {i, 0, 200}
]
I can make the count above as large as I want, no problem.
So, it seems a configuration option for Manipulate, but I am now not able to find now which option it is I need to use for this to work.
Thanks
Update
Using the Method->"Queued" as given below by Simon, now the loop works. But there are problems with this method: I can not use Mathematica while the Button is running, even with large Pauses in the loop, as it blocks the whole front end. It behaves as if the button is pressed all the time. So, this idea is out of question to use. Well, it was something to try.
btw, this is a good time to mention this, I found that using cell of type 'code' instead of the default 'input' causes many crashes in the kernel. Just tried cell type 'code' and after few clicks on the button, kernel crashed:
So I no longer use cells of type 'code'.
Back to the drawing board.
Update 2: 8/29/11, 6 PM
Using Mathematica 8.0.1, on windows 7, SP1, intel pc, here is the code that crashes it when using "code" cell
Manipulate[
Dynamic[Refresh[Text#x,TrackedSymbols->{x},UpdateInterval->0.005]],
{{x,0},ControlType->None},
{{running,True},ControlType->None},
Button[Text["play"],
{
running=True,
While[running,
x+=1;
FinishDynamic[];
]
},Method->"Queued"],
Button[Text["stop"],
running=False
],
TrackedSymbols->{None},
SynchronousUpdating->False,
SynchronousInitialization->False
]
May be someone can try the above? Had to click on start/stop few times to get it to crash.
I can reproduce this.
Update 9/2/11
on new answer: It looks Simon version (second one below) seems faster on my PC, Mathematica 8.0.1. I started both at the same time, and the Simon version seems to run faster (counter runs faster).
screen shot:
I think that it's actually the Button that is timing out, not the Manipulate.
To quote the Options > Method section of the Button docs,
By default, button functions are evaluated on a preemptive link, which
times out after 5 seconds:
Set the option Method -> "Queued" for the button and everything works as expected.
You might get better results if you let Manipulate control the "looping":
Manipulate[
If[running, x++, x]
, {{x, 0}, ControlType -> None}
, {{running, True}, ControlType -> None}
, Button["play", running = True]
, Button["stop", running = False]
]
I presume that Manipulate is being used here to support further controls within the real application. If not, then DynamicModule would be sufficient.
DynamicModule[{x = 0, running = True}
, Column[
{ Button["play", running = True]
, Button["stop", running = False]
, Dynamic[If[running, x++, x]]
}
]
]
The following example animates a moving disk using this technique:
DynamicModule[{t = 0, running = True}
, Column[
{ Button["play", running = True]
, Button["stop", running = False]
, Dynamic[
If[running, t++, t] /.
t_ :> Graphics[Disk[{Cos[t/10], Sin[t/10]}]
, PlotRange -> {{-3,3},{-3,3}}
, Axes -> True
]
]
}
]
]