I am testing a GUI (Swing based) interface and need to do it with special screen resolution. Is there any way to keep original system resolution and display the window of the application under test with specified resolution (system independent) ? Any tool for that kind of things?
Thanks,
Marcin
You can use VMWare or a similar tool to run a virtual machine. These usually allow you to specify the screen resolution.
Related
If I startup JMeter it is zoomed out way too far on my big screen. I can zoom in a lot times, but isn't there a setting to correct this?:
Assuming your operating system is windows system：
1.open \bin\user.properties
add
jmeter.hidpi.mode=true
jmeter.toolbar.icons.size=32x32
jmeter.tree.icons.size=24x24
jsyntaxtextarea.font.family=Hack
jsyntaxtextarea.font.size=28
jmeter.hidpi.scale.factor=1.8
open \bin\jmeter.bat
add
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.controlFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.systemFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.userFont=SansSerif-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.smallFont=SansSerif-20
4.start jmeter
Options -> Look and Feel -> Metal
5.restart jmeter
Set to the appearance from the beginning of Darklaf, which will be restored after reboot. Therefore, on high-resolution screens, setting it to Metal mode should be a good way.
You should be using the latest version of JMeter so try upgrading to JMeter 5.4.3 or even to nightly build
Try upgrading your Java runtime to the most recent version, it might be the case it's Java unable to properly render the elements due to lack of high resolutions support
Play with jmeter.hidpi.mode and jmeter.hidpi.scale.factor JMeter Properties, see Toolbar Display related ones in JMeter Documentation
Your "big" screen isn't very informative, going forward include screen resolution and ppi.
I wrote a compiled MATLAB GUI that we run on a remote machine via Remote Desktop. Overall it runs fine, but sometimes the GUI will blank out many of the control objects (buttons, table, popups). It seems to happen after the screen of the client computer has been locked or after the GUI has been minimized.
If you move the mouse over the buttons, popups, or table headers, they reappear. The table cells will reappear if they are selected. The GUI hasn't crashed and still works fine, but the objects just disappear until you make them reappear again. I have only seen this happen when using remote desktop (Windows-Windows using Remote Desktop Connection).
How can I get this to stop happening? It isn't really breaking anything, but it is very annoying.
I don't know if this is an issue with MATLAB or with the Remote Desktop configuration, so I posted this question here. Feel free to move this to superuser if you think it's more appropriate.
Remote Desktop has issues with handling low level rendered graphics, and interacting with graphics cards. In our experience (we use Nvidia GPU's for rendering and computation engines on multiple projects/applications) we have found remote desktop to fail in so many cases, that we have ditched it for a third party tool.
I suspect this is what you are running into.
One option I would consider, is forcing Matlab to do software rendering, if this fixes the problem, then for certain it's the graphics cards. The first hit on a google search for "matlab software rendering" returns the matlab command opengl. Reading the documentation page for that, gives the command:
opengl software
It sounds like the remote desktop minimization is causing it. For efficiency, Windows will disable various graphics when a Remote Desktop window is minimized on the client computer. To prevent this, create and set a DWORD RemoteDesktop_SuppressWhenMinimized to 2 at the following registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
After doing this minimizing and locking your screen shouldn't do anything to the RDP session. I doubt it's a graphics card issue, as Windows 10 Creator's Edition allowed remote sessions to use the remote graphics card just like as if you were running locally.
I'm running some kind of POS application which makes exclusive use of the whole desktop to not to let the user access any of the Windows system functions. To do this, I use the WinAPI functions
CreateDesktop()
OpenDesktop()
to open an own desktop and to start this application there. This works fine for one desktop.
Now there is the possibility to connect a second monitor to this PC. Windows by default extends its desktop over the full area of both monitors. But this is not a solution for my application, here I want to start two GUIs in the same manner as described above but on every monitor exclusively.
But: I do not see any possibility to hand over a monitor identifier to the functions CreateDesktop()/OpenDesktop(). So any idea how this can be done?
Thanks!
Our software should play sounds (not just small noises, but voice etc.). I wonder what about the volume control. The Windows Vista style guide lines says to define an application specific volume control in the Windows mixer.
But what about Windows XP and below? I don't think there is a way to get our control into the Windows mixer. BUT you can implement your own volume control, but if you don't modify the audio data, it cannot go louder than system wide volume (which might be very low or even mute).
The question is: should an application use it's own volume control or trigger the Windows volume control?
The problem is, that basic user doesn't even know where to setup the volume in Windows.
Most audio rendering frameworks (you don't mention which one you use) allow the user to control the audio of the stream passed from the audio rendering framework to the system audio engine. For example, DirectSound has a method IDirectSoundBuffer that allows you to set the volume for that sound buffer.
Per-application volume control (whether it's exposed via the system mixer or not) is a dramatically better experience for customers than an application controlling the master volume. Many machines (most current laptops for example) don't provide hardware volume controls and depend on the user to set the master volume to a comfortable level (which is a highly user specific value). If your application manipulates the master volume you're overriding the user choice and they're likely to be upset.
Btw, to be clear: I have no issues with MusiGenesis' choices either. For the specialized example of his application, that choice makes sense. Another similar example to MusiGenesis' example is a MIDI rendering application. If the application sometimes renders through hardware MIDI (with no volume control) and sometimes through software MIDI (with a volume control) it may make sense not to expose the volume control to the user to avoid confusion.
In my application (a software synthesizer/music composition tool) I actually don't touch the system volume or even offer a volume control for my own application. All my audio output is normalized to about 95% of the max possible level, and from that point the user can control the output volume either with the Windows volume control or the volume control on their speakers.
In my opinion, this is how a Windows audio application like this should behave, because typically when a software synthesizer is used it's the only application producing audio output, and the user already has two other ways of controlling volume (the Windows control and the speaker knob).
In the case of an application like yours, which is meant to play sounds in an environment where other applications may be making noise also, I think your application should only offer a way of lowering its own volume, without affecting the system volume. Most Windows users already know where the system volume control is (lower right toolbox), so it's kind of superfluous to add this control to your own application as well.
Our application needs to output voice as well, and also have different volume settings relative to other applications that may be running at the same time. We have a volume control that the user can change from within the application.
As such, in Windows 2000/XP, we do modify the system volume when our application gains focus, and set it back to the previous setting when we lose focus or when then application shuts down. This does work well, and does not seem to interfere with the workings of other audio based applications running at the same time (such as speech recognition software which is very sensitive to recording volume for example).
This is exactly the same behaviour as Vista and Windows 7, except that they do the work of maintaining the individual volume levels for each application (and in this case we disable the previously mentioned code).
I have a desktop computer that is hooked up to 3 different monitors of which only two can be active at any one time. One is a primary monitor and is always active. I can manually switch between the other two: one a monitor, another an HDTV.
The switch is a mechanical switch which only handles VGA (and at that, only the RGB components are actually switched) so there is no feedback to the computer from the other devices, thus windows can not make any automatic adjustments to change resolutions and things like that.
I want to make a batch file that will automatically switch the screen configurations and resolutions (hard coding the proper resolutions of course since we can't detect the other devices anyways) so that they are correct for the displays.
Where is the best place to get started? Where can I find library of commands (or whatever they are called) to do something like this? Lastly, is there anything I should be careful about when attempting something like this?
Thanks in advance,
-Faken
Try reschangecon (yes, there is a console version!).
It is safe, because it won't let you set settings that are not supported (without the force flag).
http://www.12noon.com/displaychanger.htm (It is free for personal use)
I've used ResSwitch to do this on my friend's HTPC that periodically forgot what resolution to drive his TV at, you call it like this: resswitch.exe 1920 1080 32 60
http://www.naughter.com/qres.html
The risk is it doesn't ask you to confirm, so you better be sure your monitor can handle the resolution you're asking for.