I've tried the simple program for my exercise but if i compiled, it turned give a message "No Way to get the console handle" (Dev-Pascal).
Here's my code:
program square;
uses crt;
var
side,circumference,broad:real;
begin
write('Input the side value of the square: ');
readln(side);
circumference := 4 * side;
broad := side * side;
writeln('The circumference value of the square = ', circumference);
writeln('The abroad value of the square = ', broad);
writeln();
write('Press any key...');
readkey();
end.
thank you for helping and teaching me
i would appreciate
Dev-pascal comes with a 10+ years old Free Pascal version. I really have no idea. Try to run the example on the cmdline to see if dev-pascal is the cause or something else. Temporarily disable security software might also be something to try.
I suppose, you've created a Window Skeleton project.
It has it's description: A Windows skeleton application (no window).
In this case you'll get this error though you code compiles (I've got this error too with your code).
Try to create Console Application project which has it's own description: A standard console-based (MS-DOS) application (Your code has compiled and the program worked as well).
P.S. Can't say what exactly happens -- couldn't find any documentation about errors in Dev-Pas (1.9.2).
My assumption is that skeleton program doesn't imply console window for execution program while console application does.
just close the project and then re-open the pascal source file (.pas). And maybe put "readln;" just before "END.".
Related
I dont know how to make this working or I am missing something - maybe in #include ?
at this point I have:
#RequireAdmin
#include <MsgBoxConstants.au3>
#include <FileConstants.au3>
;vcdredist
Run($sDrivers & "\vcredist_x86.exe")
WinWaitActive("vcredist_x86")
;ControlClick("Microsoft Visual C++ 2010 x86 Redistributable Maintenance", "","[CLASS:Button; INSTANCE:3]")
ControlClick("Microsoft Visual C++ 2010 x86 Redistributable Maintenance", "","[ID:105]")
I've checked with AutoIt v3 WIndow Control and arguments inside ControlClick are correct
none of last two lines make AutoIt select desired option.
Any help very much appreciated.
WinWaitActive()
Probably Isn't the thing you're looking for, as it waits for the window to be active for the code to be ran. WinActivate() activates the window.
If you want the code to run when you activate the window, then WinWaitActive() will do.
Also you can avoid having the title in the ControlClick by doing this.
$hWnd = WinWait("vcredist_x86")
WinWaitActive("vcredist_x86")
ControlClick($hWnd, "", "[CLASS FROM AUTOITINFO]", "Left", 1)
Use the Autoit Window Info tool to find the classes if you aren't using it already.
(https://www.autoitscript.com/autoit3/docs/intro/au3spy.htm)
If ControlClick still doesn't work, then you can try using
MouseClick("Left", x, y)
X, Y are the coordinates.
Probably the script is waiting to the window become active WinWaitActive().
In this case you can use a WinActivate before the WinWaitActive to avoid this problem.
If you want a more robust solution you can use this:
While Not WinActive($win)
WinActivate($win)
Sleep(500)
WEnd
I wrote a UDF in AutoIt to wait for controls. posted around here a few times. just feed it the stuff you want and how long, if applicable you want to wait. you can wait forever by default.
However, there is an easier solution, install it in quiet mode. run a command
Run($sDrivers & '\vcredist_x86.exe /q')
now you don't have to poke any buttons. also, it's better not to use ID because if you are testing an application that is changing, the developers can change all that. I use button text as additional search criteria instead. much more reliable and less maintenance on my code.
Have gone through the similar situation for one application while trying to automate that, after trying all the debugging just added the below command and it worked like charm
#RequireAdmin
I just upgraded to Xcode 7 and I can no long use the NSLog statement to show messages for debugging? NSLog(#"I am at the start of the loop"); This used to work and now I can't even write the statement in the code, it gives me a "expected parameter declarator"? What am I missing? I researched this and can't find anything saying it's changed. One day it worked and now it doesn't. I can find it in my older projects and it still works within those older projects. Any help would be appreciated.
Try Shift + + C (equivalent to View > Debug Area > Activate Console)
Credit to this original answer
I wish to simulate a right click on a file. This is done by opening a Windows Explorer window and then right clicking on it.
The main issue is finding the location of the file in Windows Explorer. I am currently using Autoit v3.3.8.1.
My code 's first line:
RunWait (EXPLORER.EXE /n,/e,/select,<filepath>)
The next step is the problem. Finding the coordinates of the file.
After that, right clicking at that coordinates (it seems to me at this time) is not a problem....
Some background:
OS: Windows 7 64-bit
Software Languages: C#, Autoit (for scripting)
The Autoit script is called by a code similar to that below:
Process p = new Process();
p.StartInfo.FileName = "AutoItScript.exe";
p.StartInfo.UseShellExecute = false;
p.Start();
The code is compiled into a console class file which is run at startup. The autoit script runs as the explorer window opens up.
It seems as though you are taking the wrong approach to the problem, so I'll answer what you are asking and what you should be asking.
First up though, that line of code is not valid, and is not what you want either. You want to automate the explorer window, and RunWait waits for the program to finish. Furthermore you want those items to be strings, that code would never work.
Finding the item in explorer
The explorer window is just a listview, and so you can use normal listview messages to find the coordinates of an item. This is done most simply by AutoIt's GUIListView library:
#include<GUIListView.au3>
Local $filepath = "D:\test.txt"
Local $iPid = Run("explorer.exe /n,/e,/select," & $filepath)
ProcessWait($iPid)
Sleep(1000)
Local $hList = ControlGetHandle("[CLASS:CabinetWClass]", "", "[CLASS:SysListView32; INSTANCE:1]")
Local $aClient = WinGetPos($hList)
Local $aPos = _GUICtrlListView_GetItemPosition($hList, _GUICtrlListView_GetSelectedIndices($hList))
MouseClick("Right", $aClient[0] + $aPos[0] + 4, $aClient[1] + $aPos[1] + 4)
As has already been mentioned, sending the menu key is definitely a better way than having to move the mouse.
Executing a subitem directly
This is how it should be done. Ideally you should never need an explorer window open at all, and everything can be automated in the background. This should always be what you aim to achieve, as AutoIt is more than capable in most cases. It all depends on what item you want to click. If it is one of the first few items for opening the file in various programs, then it is as simple as either:
Using ShellExecute, setting the verb parameter to whatever it is you want to do.
Checking the registry to find the exact command line used by the program. For this you will need to look under HKCR\.ext where ext is the file extension, the default value will be the name of another key in HKCR which has the actions and icon associated with the filetype. This is pretty well documented online, so google it.
If the action is not one of the program actions (so is built into explorer) then it is a little more complex. Usually the best way will be to look at task manager when you start the program and see what it runs. Other things can be found online, for example (un)zipping. Actions like copy, delete, rename, create shortcut, send to... They can all be done directly from AutoIt with the various File* functions.
With more information, it would be possible to give you more specific help.
First, you might want to look at the Microsoft Active Accessibility SDK. In particular look at this interface...
http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx
You can use this to walk the items in the control and find the one with the file name you are looking for and its screen location.
From there, maybe try something like this for simulating the right click.
How can I use automation to right-click with a mouse in Windows 7?
Once you have done the right click, use accessibility again to find the right option on the context menu.
Maybe there's an easier way, you should be able to cobble something together like this if you don't find one. Good luck!
Suppose I have a file named test.txt on D drive. It needs to right click for opening Context Menu. To do this, the following code should work:
Local $filepath = "D:\test.txt"
Local $iPid = Run("explorer.exe /n,/e,/select," & $filepath)
ProcessWait($iPid)
Sleep(1000)
Send('+{F10}')
I'm looking for a good tutorial on how to use modeltest to test models based on QAbstractItemModel. I don't know how to interpret debug messages that are displayed.
Also I'm having trouble configuring modeltest project to work with my app in QtCreator. Including the .pri/.pro doesn't work. I get an error saying "No rule to mage target ..". After fixing paths in modeltest/modeltest.pro file it starts to compile. But i get this wierd assertion
ASSERT: "QTest::testLogger" in file c:\ndk_buildrepos\qt-desktop\src\testlib\qtestlog.cpp, line 232
Any ideas why this happens ?
My modeltest folder is located inside my project. I added following line at the end of my *.pro file
include(modeltest/modeltest.pri)
The modeltest.pri file contains the following
load(qttest_p4)
SOURCES += modeltest/modeltest.cpp modeltest/dynamictreemodel.cpp
HEADERS += modeltest/modeltest.h modeltest/dynamictreemodel.h
I modified my code to use modeltest this way
model = new TasksModel(this);
new ModelTest(model, this);
ui->treeView->setModel(model);
TasksModel is my implementation of QAbstractItemModel model.
ui->treeView is the widget that displays data.
No other modifications where made while integrating modeltest with my app.
Qt version is 4.7.
This will sound a little overgeeky - but it is, in fact, what the ModelChecker dev intended for you to do ;) When you hit one of the asserts, go to the point in the code where it is hit and read the comments which are written along with it. The entire thing is extremely heavily commented, and describes what is breaking and likely reasons why. This is by far easiest to do if you run your app through a GUI debugger, such as that included in for example KDevelop, Qt Creator or Visual Studio.
The reason you are getting this error is because you aren't actually using the ModelTest inside a proper QTestLib test case. If you take a look at /tests/auto/modeltest (where you presumably got the modeltest class in the first place), you can see how to properly construct a test case using the ModelTest.
I've been playing around with some ANSI stuff (like colors etc.) in java and php (from scratch) and I'm trying to find a way to basically wait for a key press. I'd like to have something like the following pseudo code at the end of my main event loop:
If (KeyPressed)
Begin
var event = new KeyboardEvent();
event.Key = ReadKey();
this.BubbleEvent(event);
End
But everything I've been trying over the last couple days fails because the key presses only become available on STDIN after the user has pressed enter.
It doesn't matter much what language you answer in, but java, php, plain old c or c# would be nicest, and I cannot use any really spiffy library stuff because I need to port it to all four of those languages... I need this to work over a telnet or ssh connection, but my research so far suggests it is impossible unless you're working on the local machine.
Please prove me wrong.
The curses function cbreak(3) will disable line-buffering and erase/kill handling. You can do this yourself with stty(1) if you really want.
When your program dies and leaves the terminal in cbreak mode, you can usually use either stty sane or reset to bring the terminal back to a reasonable state.
From within Perl, you can use either the Term::ReadKey or the Curses module to manipulate the terminal. See the Term::ReadKey(3pm) or Curses(3pm) manpage for details.
From within C, you can use either ioctl(2) calls on the terminal device to turn on cbreak mode, or you can use curses. See the ncurses(3) manpage for details.
I know, this is an old thread, but I could not find a suitable answer anywhere else. So with some help from the senior programmers of my company I came up with this:
private void waitKeypress() throws IOException
{
System.in.read();
while ( System.in.available() > 0 )
{
System.in.read();
}
}
The part reading as much input as is available solved my problem that when used multiple times, "System.in.read()" alone does not always wait.
For me this does the trick, I use it like this:
doSomething();
waitKeypress();
doNextThing();
Hope it helps.
Kind regards,
Ralph