I'm currently working on a small GUI based application using gWidgets (RGtk2).
I've encountered a question which I was unable to solve by myself using the documentation provided in the gWidgets package:
Is it possible to trigger an event, i.e. a function, when the user clicks on the red cross to close the GUI / widgets/ main window? For usability reasons I don't want to have an extra button though it will definitely work.
PS: I don't think an example is necessary here but if any of you insists I will add one.
Try
addhandlerdestroy( myWidget, handler = f_exit )
where
f_exit <- function( h,...
{
# your code, maybe simply
dispose( myWidget )
}
Related
I need to load a large file to parse and draw with OpenGL. The whole process is very time-consuming. So I want to realize a prompt dialog box before parse. But the code as following is not work.
void parseFile()
{
QMessageBox* msgbox = new QMessageBox();
msgbox->setModal(false);
msgbox->setWindowTitle(tr("message box"));
msgbox->setText("Please wait patiently......")
msgbox->show();
/* parse file and draw */
......
}
But it shows like also be frozen:
How to realize it?
show() does not actually show the content of the dialog. It only tells the event loop to show the dialog ASAP. But since you call more code after immediately after show(), the evnt loop does not have a chance to do its work.
The easiest way to solve this is to call QCoreApplication::processEvents() after msgbox->show(). This will force the event loop to do the work immediately.
If this does not work then try this parameter QCoreApplication::processEvents(QEventLoop::WaitForMoreEvents)
Another option would be to move the heavy calculation to a function and than show the dialog and then schedule the calculation using a timer.
...
msgbox->show();
QTimer::singleShot(0, &doHeavyWork);
This would first handle all events related to showing the dialog and only after that it will start the heavy work (i.e. parsing the file).
i want to implement a QProgressbar for a function in my GUI. I thought the process is simple but it seems not to be.
I thought i can implement the bar like this:
1- Button clicked
2- Progressbar and function start simultaneously
3- Function and Progressbar end simultaneously
What i have found when i searched is the update of this bar with a for-loop.I don't want to do so because my code is a simple function that must be run only one time.
Is it possible to do so ? Or am i misunderstanding something ? I found that the start and stop signals have to be managed with Threading. I wanted to ask here before i go and do further search.
Thanks.
I think the best practice is, using the main thread for QProgressbar or QProgressDialog and side thread for your function.
When main thread is used for your function, the UI won't be updated, even you use for-loop to setValue.
What I am doing is, create a QThread like with a signal giving out the progress:
class AThread(QThread):
progress = pyqtSignal(int)
def run(self):
for i in range(100):
self.progress.emit(i)
Then set the value of progressbar using the number in the signal
Here is the simplest possible example:
library(gWidgets)
gmessage("error test", icon="error")
gmessage("error test", icon="error")
If you choose tcltk as the gui toolkit the code works as expected, i.e. when the dialog appears clicking 'cancel' button dismisses the dialog and returns control back to your R session. But if you choose RGtk2, the second call to 'gmessage' does not produce any dialog or it is invisible, and as the 'gmessage' is a modal dialog, you lose control of your session.
If this is not a bug, please tell me what the correct way of calling 'gmessage' with RGtk2. Thank you.
P.S. There is a reason I don't provide parent/container as an argument. Just don't want to widen discussion.
P.P.S. I use R 2.14 (company decision) on openSuSE.
I have written a GUI in R with RGTK2 and Tcltk that does a lot of fairly heavy calculations and aggregations on big data sets.
I would like to find a way to stop the user interface from accepting user inputs while it is processing a large data set, and ideally, change the interface color, popup a dialogue, or change the mouse pointer to an hourglass/spinner to indicate to users that the application is active.
The implementation that I want would look something like:
gSignalConnect(bigRedButton,"clicked",
f=function(widget)
{
something$start() # object with method that blocks further user input
# and pops up loading bar or "Processing" dialogue
# (or possibly spins the mouse)
# Code that does a very big set of calculations
something$stop() # unblocks user inputs and removes visual impedance
}
)
I have tried using gtkDialogue to solve the problem, but this seems to stop execution of the whole program until one closes the dialogue, which rather defeats the purpose.
Any help would be greatly appreciated.
So the magic method is gtkWidgetSetSensitive:
gSignalConnect(bigRedButton,"clicked",
f=function(widget)
{
gtkWidgetSetSensitive(Window,FALSE)
# Code that does a very big set of calculations
gtkWidgetSetSensitive(Window,TRUE)
}
)
This method turns the targeted widget (which can be an individual button, textEntry, comboBox, etc...) gray and blocks input.
I am using a coded UI testing harness that looks at a jQuery grid that we have written. The problem that I am encountering is that when the grid pages, the coded ui keeps track of the old controls when I try to call the paging again. I guess an example would explain it better:
BaseMap.MSMaintenanceMap.PageNext();
BaseMap.MSMaintenanceMap.PageNext();
this is the code that I am trying to get to work. The problem is here in the generated designer file:
if ((this.mUITitlePagingRowRow == null))
{
this.mUITitlePagingRowRow = new UITitlePagingRowRow(this);
}
When I change it to this:
this.mUITitlePagingRowRow = new UITitlePagingRowRow(this);
it works every time. Problem is when the uitest gets re-generated, this reverts back for obvious reasons. Is there any additional parameters that anyone knows that I can put in the .uitest file to always get the latest version of a control?
Add AlwaysSearch to the SearchConfigurations of the control, this forces the test not to cache the control but always look for it using the defined properties. Hope this helps.
You can refresh the map from your test method. So when you are calling the method in the partial class for a second time just put something like BaseMap BaseMap = new BaseMap(); Then this will refresh the map and you can call BaseMap.MSMaintenanceMap.PageNext(); without the refresh problem.
Another way around this is to not rely on BaseMap.Designer.cs. You can manually write the method in the BaseMap.cs partial class. This does not get generated. Record the PageNext() object into the map. Then write a method like this:
public void PageNext()
{
BaseMap = new BaseMap();
Mouse.Click('TheObjectYouRecorded');
}
Hope this helps.