I can't find anything about this. I know GLFW has a way to get attributes:
GLFW: window related attributes
But nothing to check if a window is in windowed mode.
The reason I want to know this, is that when the current monitor gets disconnected the window
is set to windowed mode. But I don't know if it gets "restored" to full-screen" when the monitor reconnects.
I currently store a boolean in the window class for whether the window is in windowed mode.
And use this when i change resolutions etc. I can set "windowedMode = true" when the
monitor disconnects. But atm. I can't know if I should set it to false if it reconnects.
I only have one monitor (laptop) and can't test this out for myself. Either way, it could be useful
to know if you can query that.
GLFWmonitor* monitor = glfwGetWindowMonitor(window);
"For windowed mode windows, this function returns NULL. This is how to tell full screen windows from windowed mode windows."
GLFW: Window monitor
If the return value is NULL it could also be an Error, so you would have to check for that:
GLFW: Error handling
Related
My Android application, being prepared in Android Studio 3.5.3, has a layout with more than 80 different views (and this number will grow). So, the warning layout has too many views appears. I'd like to increase variable ANDROID_LINT_MAX_VIEW_COUNT up to 100 (as it is advised in the warning), but I cannot find where it can be done. Menu File->Settings->inspections does provide option Perfomance->Application size->layout has too many views describing this warning, so it is possible to suppress it. However, I'd like just to increase ANDROID_LINT_MAX_VIEW_COUNT, not to suppress it at all. I've found an advice to create environment variable ANDROID_LINT_MAX_VIEW_COUNT setting it to 100, but it does not work.
Thanks for any idea
ANDROID_LINT_MAX_VIEW_COUNT is indeed an environment variable. After setting it to a proper value, Android Studio has to be restarted, that I didn't. After restarting, the warning layout has too many views disappeared.
I'm trying to get FLTK running in my c++ project. I'm creating an OMNeT++ simulation and would like to use the GUI like an emulated host, that is, I can make a send button and the host attached to the GUI will queue up a message to send in the simulation.
The issue I'm having is that, when the FLTK window runs, it waits for a response which causes the whole simulation to freeze until I close the window. My solution was to run the GUI in a separate thread. However, now I'm getting this error:
Tcl_ServiceModeHook: Notifier not initialized
Below is the code for the class containing the thread and the GUI.
#include <Enumerations.H>
#include <Fl.H>
#include <Fl_Box.H>
#include <Fl_Widget.H>
#include <Fl_Window.H>
#include <GUI.h>
void GUI::callThread() {
t = std::thread(&GUI::openWindow, this);
}
int GUI::openWindow() {
Fl_Window *window = new Fl_Window(300,180);
Fl_Box *box = new Fl_Box(20,40,260,100,"Hello, World!");
box->box(FL_UP_BOX);
box->labelsize(36);
box->labelfont(FL_BOLD+FL_ITALIC);
box->labeltype(FL_SHADOW_LABEL);
window->end();
window->show();
return Fl::run();
}
All I do to call it is:
GUI *g = new GUI();
g->callThread();
If I instead just call openWindow() directly, The window opens fine but it waits for an action so the rest of the simulation is not able to continue.
I'm trying to make this cross-platform (Has to work on Mac and Windows). I tried Qt (too complicated to set up) and wxWidgets (make errors on my computer) so FLTK seemed like one of the next best choices.
If anyone knows how to fix this error or has any opinions on a better way to set up my GUI, I'm all ears. This just seemed like the only thing I could do.
OMNeT++ 5.0 and up has Qtenv, which is a QT based runtime (Tkenv is now deprecated), so the whole QT setup, dependency etc. is done for you by OMNeT++. Qtenv will be the default runtime in OMNeT++ 5.1
It's not really clear what you are trying to achieve. If you want to insert events into the event queue whenever you press a button, you definitely have to use a separate thread, but you have to clarify how the simulation and wall clock time is related to each other. If they must be synced, you need to implement a real-time scheduler that syncs the simulation time with the wall clock time. The sockets example in OMNeT++ does this and behaves similarly what you describe except that the external event inserted into event queue is coming from a socket (where you can attach with a browser) isntead of coming from a GUI.
If you don't care about synchronization i.e. you want to use this for some kind of demonstration, then you don't have to use a real-time scheduler, but you should be aware the OMNeT++ is inherently single threaded and your GUI is running in a separate thread, so you have to sync those too. i.e. It's absolutely forbidden to access ANYTHING that OMNET is using from the GUI thread (or bad things will happen).
And the poor man's solution: if you just want to trigger an event (i.e. you really need only a button). Write an application in the host which regularly polls a volatile bool parameter. If it finds the parameter "true" it sends the event and then sets the parameter to "false". Now how you trigger an event? You can browse the parameters of the given node in the property inspector (lower left panel in runtime) and you can change it's value by hand back to true, then allow the simulation to continue. On the next poll, the host's app will detect again that the parameter is true and do the sending again. Obviously it's limited, but it gives a limited interaction without writing too much code (and all the multithreading issues are handled by the runtime itself)
So I'm developing an OS using C# and Cosmos. It's called Memphis, and I want it to be entirely command-line for now (like DOS).
But, something that most command-line OSes I've seen (Arch, DOS, etc) all have something like a console library that lets you create simple UIs with buttons, menus, inputs, etc.
I've already tried to write my own, but it was completely futile. I can draw a window and text on-screen, but not much else (I did have a basic window manager that kind of worked but didn't, you press tab to switch between windows, and left/right to select inputs like buttons, textboxes, etc and it did accept keyboard input and I could see the windows updating, but nothing actually changed despite the code theoretically working)
So I'm looking for a way for me to draw UIs on the console for my OS, but it has to be ENTIRELY managed, and must ONLY use what's in System.Console. It also CANNOT contain events. This is because, Cosmos can only really work with code that's 100% managed, and System.Console is implemented almost fully in Cosmos, and events throw an 'OpCode Mkrefany not yet implemented' when Cosmos' IL2CPU assembler tries to convert the compiled c# code to x86 ASM.
During working with a constantly growing ERM, I came to the idea that a view-toggle feature would be very neat, so I can e.g. hide all tables depending to the plugin xyz.
I am working with MySQL Workbench and found this answer in the documentations:
In some circumstances, you may want to make a layer invisible. Select the layer and, in the Properties
palette, set the visible property to False.
My problem is: There is no Visible property, not in the properties of single tables, neither in the properties of Layers.
I am using the newest version of the tool.
Does somebody knows what's going wrong (perhaps there's a special setting/configuration to use that property), or if somebody knows if they have removed this function?
When I am debugging broken code, after a while the browser announces that the Flash plugin has crashed, and I can't continue debugging my code. Can I prevent the browser from killing Flash?
I am using Firefox.
Going to the debugger on a breakpoint makes the plugin "freeze". This is intentional, it's a breakpoint after all!
However, from the browsers perspective, the plugin seems to be stuck in some kind of infinite loop. The timeout value varies, my Firefox installation is set to 45 seconds.
To change the timeout value go enter about:config in the url field and look for the setting dom.ipc.plugins.timeoutSecs increase this or set it to -1 to disable the timeout altogether.
When the plugin crashes, it does in fact not so, because the browser is "killing" it, but rather the plugin terminates itself when a fatal error occurs. This is necessary to prevent the browser, or even your entire machine from crashing - there is no way to tell what is going to happen after an error like that. And besides: After the first uncaught error, your program will likely not be able to perform even correct code the way you intended, so you won't do any good by continuing a broken debugging session. So it is not a flaw, it is actually a good thing this happens!
However, you can do some things in order to work more effectively (and make your programs better). The most important I can think of right now are:
Learn to use good object-oriented programming techniques and get acquainted with design patterns, if you haven't already done so.
Take extra care to prevent error conditions from happening (e.g. test if an object is null before accessing its properties, give default values to variables when possible, etc.)
Use proper error handling to gracefully catch errors at runtime.
Use unit tests to thoroughly test your code for errors one piece at a time, before debugging in the browser. Getting to know FlexUnit is a good place to start.
EDIT
I should also have said this: A Debugger is a useful tool for stepping through your code to find the source of an error, such as a variable not being properly initialized, or unexpected return values. It is not helpful when trying to find out what's happening after a fatal error has occurred - which will also not help you to fix the code.