This seems a rather silly question: but I can't find (for more than an hour) now a button to "reset" all standard windows.. I accidentally closed quite a lot of them during a crash. (Especially the "command window" and the signals-in-region during simulation seem to be gone permanently).
From "ModelSim User’s Manual, v10.1d", appendix F:
Most user GUI preferences are stored as Tcl variables in the .modelsim file on Unix/Linux
platforms or the Registry on Windows platforms.
You may consider to look into .modelsim, and possibly delete it, together with .modelsim.bak. The motivation for this suggestion is that .modelsim contains setup details for the layout of panes. .modelsim will (should!) be regenerated next time you open modelsim.
At the menu bar (main window), click on layout and then choose reset. Most of the windows will be reset.
Related
I'm writing a quick&dirty number crunching test, using a Qt console application.
It prints several thousand lines, but the number of lines displayed in the console seems to be limited to about 300. This means that at the end I can no longer scroll back to the beginning of my printout.
How can I raise this limit? I found nothing in the project settings.
Or is it completely impossible, as the console window is controlled solely by my operating system?
It's important for me to launch the program directly from Qt creator, so a solution where I use a batch script or similar trick to run my program is not preferable.
Does a solution even exist, or am I forced to switch to a Qt GUI application where I create my own console out of a QTextEdit widget?
The number of lines displayed and the number of lines in the buffer is a property of the operating system. You can change this. How to do this depends on your OS.
We are using Progress OpenEdge 10.2A for years and for the last 4 months we begin to receive unknown error messages from our customers.
We call our .w files using lines as follows:
RUN VALUE(myPath + "myProgram.r") PERSISTENT SET myPrograms[i].
Normally the same program calls work without any problem, but on rare occasions, the program window seems to get unresponsive, but in fact when we look at the windows taskbar, there is another entry in the taskbar which is a prowin32.exe window having title "Error". But when selected, there seems to have no visible window attached to it.
When we close it from the taskbar using Close Window option, it appears again in the taskbar 6-7 times again and then whole prowin32 session restarts.
We could not identify the error since it does not show any message or any error number.
If you encounter such a problem, I'd like to know how you solved it.
If not, it would be appreciated if you direct me to the way to solve the problem.
Edit 1:
After adding -errorstack -debugalert -clientlog myLogFile.log to my startup parameters, myLogFile.log is generated. The below part is written when the error occured.
**Unable to realise TEXT myText. (4025)
** ABL Debug-Alert Stack Trace **
--> enable_UI c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 21014
c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 14858
USER-INTERFACE-TRIGGER c:\myFolder\myFile2.r (c:\myFolder\myFile2.r) at line 2905
0) OpenEdge 10.2a is ancient, obsolete and unsupported. You should have moved to a modern release 10 years ago. At the very minimum you should be on 10.2b08. Do you also refuse to update Windows? OpenEdge 12 is the current release. It is possible, perhaps even likely, that unanticipated changes in Windows or other aspects of the environment are causing your problem. Progress is never going to update 10.2a to accommodate that sort of thing. You are just prolonging the agony by staying on an obsolete release.
1) What changed in your code or your environment 4 months ago?
2) You can get a stack trace for the extra prowin32 session by running proGetStack. That should help to explain what was launched, what the error is and why another 6-7 start after you kill it. Open a "proenv" window as "Administrator" and run proGetStack (you can get the process id from taskmgr).
proenv> proGetStack 123456
The stack trace will appear in the working directory of the target process. That is usually the same directory that proenv is in but it is possible that the application changes it so you might have to go hunting for it. (Administrator proenv windows sometimes do not start in %wrkdir%, you may also need to cd /d %wrkdir%)
3) If they are not already present you should add -debugalert and -errorstack to your client startup parameters. -clientlog logfileName.log would probably also be helpful.
4) Examine your code base for bits that invoke prowin32 sub-processes. There are many ways to do this such as OS-COMMAND, INPUT THROUGH or via Windows DLL calls. Directly invoking prowin32 can be found by searching for that string but it might also be indirect invocations via a BAT file or other technique.
5) if you have a repeatable way to produce the error then you could also add the 4GLTrace log entry type either at startup or in the code when you get to the proper point: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpspr/log-entry-types-(-logentrytypes).html
I am trying to show a progress in the taskbar of the plasma desktop using the KDE Frameworks. In short, it want to do the same thing as dolphin, when it copies files:
I'm kinda stuck, because I don't even know where to get started. The only thing I found that could be useful is KStatusBarJobTracker, but I don't know how to use it. I could not find any tutorials or examples how to do this.
So, after digging around, and thanks to the help of #leinir, I was able to find out the following:
Since Plasma 5.6 KDE supports the Unitiy DBus Launcher-API, which can be used, for example, to show progress
I found a post on AskUbuntu that explains how to use the API with Qt
The real problem is: This only works, if you have a valid desktop file in one of the standard locations! You need to pass the file as parameter of the DBus message to make it work.
Based on this information, I figured out how to use it and created a GitHub repository, that supports cross platform taskbar progress, and uses this API for the linux implementation.
However, here is how to do it anyways. It should work for KDE Plasma and the Unity desktop, maybe more (haven't tried any others):
Create a .desktop file for your application. For test purpose, this can be a "dummy" file, that could look like this:
[Desktop Entry]
Type=Application
Version=1.1
Name=MyApp
Exec=<path_to>/MyApp
Copy that file to ~/.local/share/applications/ (or wherever user specific desktop files go on your system)
In your code, all you need to do is execute the following code, to update the taskbar state:
auto message = QDBusMessage::createSignal(QStringLiteral("/com/example/MyApp"),
QStringLiteral("com.canonical.Unity.LauncherEntry"),
QStringLiteral("Update"));
//you don't always have to specify all parameters, just the ones you want to update
QVariantMap properties;
properties.insert(QStringLiteral("progress-visible"), true);// enable the progress
properties.insert(QStringLiteral("progress"), 0.5);// set the progress value (from 0.0 to 1.0)
properties.insert(QStringLiteral("count-visible"), true);// display the "counter badge"
properties.insert(QStringLiteral("count"), 42);// set the counter value
message << QStringLiteral("application://myapp.desktop") //assuming you named the desktop file "myapp.desktop"
<< properties;
QDBusConnection::sessionBus().send(message);
Compile and run your application. You don't have to start it via the desktop file, at least I did not need to. If you want to be sure your application is "connected" to that desktop file, just set a custom icon for the file. Your application should show that icon in the taskbar.
And thats basically it. Note: The system remembers the last state when restarting the application. Thus, you should reset all those parameters once when starting the application.
Right, so as it turns out you are right, there is not currently a tutorial for this. This reviewboard request, however, shows how it was implemented in KDevelop, and it should be possible for you to work it out through that :) https://git.reviewboard.kde.org/r/127050/
ps: that there is no tutorial now might be a nice way for you to hop in and help out, by writing a small, self contained tutorial for it... something i'm sure would be very much welcomed :)
I use squish-4.2.2 for testing GUI of our tool and use purecov.i386_linux2.7.3 for covering them. Our tools are based on qt-4.7.4_qsci version of QT. After building our tools in Purecov mode, when we run our tests, they fail if tests contain operation with "popsup menu". Purecov cannot generate the result *.pcv file. Also I would like to note that our tools do not fail when they are run without Squish, however "Popsup Menu" opens not earlier than after 30-60 seconds (in normal mode it is done during 1-2 seconds).
So I have 2 issues:
1. when tests are run with Squish, they fail when tests contain operation with "Menu" item;
2. Purecov does not generate *.pcv file when tests fail.
I tried to find some interesting things on your site for resolving those problems, but I couldn't find anything related to my issues.
In my opinion, Squish failed because when I try to open "Menu" item, GUI runs faster than its logic part, and after opening "Menu" item, Squish considers that operation is done and kills my tool.
Could you please tell me what I can do with my tests or tools for resolving those problems?
Thanks.
I had a similar issue in the past, with clicking menus from my app.
I hope this helps you also!
Example:
I wanted to open a "File" menu, followed by a sub-menu (which is pop-up) "New". When I'm in record mode of Squish, Squish records the following code in python:
activateItem(waitForObjectItem(":MainWindowForm.m_poMainMenu_QMenuBar", "File"))
activateItem(waitForObjectItem(":MainWindowForm.menuFile_QMenu", "New..."))
Now, this didn't worked all the time, honestly I didn't managed to understand why :).
But, I found on their site, this a possible solution. So, I've replaced Symbolic names from the code above, and created a function that calls the objects after Real name properties:
def callMenu(menu_name, submenu_name):
activateItem(waitForObjectItem("{type='QMenuBar' visible='true'}", menu_name))
activateItem(waitForObjectItem("{type='QMenu' title='%s'}" % menu_name, submenu_name))
After I made this change, the tests run smooth, without anymore problems (at least from the menu side).
Anyone know how to set Notepad++ as default text editor for SAS, Stata and R?
I'm having the hardest time finding anything online (particularly for SAS). Looking for ability to run code from Notepad++ as well as setup color coding.
Thanks.
Why not just go the GUI route: right click, e.g., any foo.R file and select "Open with...", then pick Np++ and click the "always open this file type.." button. Rinse, lather, repeat.
BTW, for R, if you don't already have it, get "NppToR" , a little app which lets you execute code directly from the Npp window.
On windows you can either:
manually edit the keys for the file type to set the value of HKEY_CLASSES_ROOT\FILE_TYPE\shell\edit\command where FILE_TYPE is the appropriate one for each of the files extensions you wish to change this is quite hard work or
you can use a program that does it for you such as the free Default Programs Editor
In either case the first thing to do is to back up the registry.
I would seriously suggest looking into using one of the many, some free IDEs as they will automatically include the run from edit environment, syntax highlighting, code completion and, in many cases, debugging as well.
Notepad++ is my favorite editor and I was in the same shoes as you are now.
I am assuming that you are in Windows (Notepad ++ doesn't exist in Mac, saddest thing for me)
Please follow the steps mentioned in the below webpage and do as the author says.
http://hafniumcity.com/notepad_color.php
Now for in-line editing , it may be not be the best choice for SAS. Although I haven't tried it much so not a good person to comment on it.