If you type a password in a modern application, it usually displays a nice neat black circle - where more traditional app's would use an asterisk. How is that character created? Is it an ascii value (if so I can't find it)? If not, how is it created?
U+25CF BLACK CIRCLE: ●
At least for android this one is the correct one •
\u2022 or U+2022
Firefox for instance uses mainly two variations internally:
For Windows they use ● 'BLACK CIRCLE' (U+25CF). (as seen here)
For Mac and Android they use ● 'BULLET' (U+2022). (as seen here)
For Linux they use the systems internal "invisible-char", not quite sure which character that is.
Related
On FEI machine, dark field tilts are done by changing "beam LX", "beam LY", "beam UX", "beam UY" defelectors. Are there commands to access this tilt?
I tested out using EMGetBeamTilt(x,y). There is no change on those numbers when changing DF tilt.
Also tried "void EMGetProjectorShift(number x, number y)". This command does not exist in GMS 1.x.
Using "EMSetBeamTilt(x,y)" works to achieve the similar result. I am looking for that way to emulate the DF control used on FEI. Reason 1 is the speed. EMSetBeamTilt is very slow on FEI. Reason 2, hysteresis is strong. Reason 3, it is nice to sync the hardware knob and the script to enhance interactive capability.
GMS 1.x is very, very outdated (on par with WinXP) and didn't even have a supported script-interface for microscope control. (It did have unofficial commands though.)
Microscope control commands were officially introduced and supported with GMS 2.3 ~2012 and going forward, but they are limited in nature as they represent the common denominator of various microscope vendor's hardware interfaces. (i.e. they have to work with all microscopes).
Documentation has since been pretty up-to-date, with some commands being added over time in higher GMS versions. So the short answer to the actual question is:
You have the commands that are documented in the F1 help documentation and there are generally no additional commands.
Depending on your system there might be crude workarounds, though.
f.e. if you system has it's own interface for Python or VisualBasic, one can write a script command to call those interfaces. (Python since GMS 3.4)
I would like to take a screenshot of a web site using WebGL. I don't have to use GPU to open that site. Using emulation is enough for me.
At the beginning, I already tried headless-chrome to do this. That can take screenshot of ordinal web sites. But, It not works for WebGL canvases.
I think one of possibility is using OSMesa or something to emulate OpenGL.
I have used all of my strategy for overcoming this. Is this actually possible to do?
If yes, please tell me how to do that. If no, I would like to know why.
Thanks.
Yes it is possible!
You need the right combination of:
headless-chromium binary
libosmesa.os binary (in same directory)
launch chrome headless with the right flags, such as (see link for full details): ['--use-gl=osmesa', '--enable-webgl', '--ignore-gpu-blacklist', '--homedir=/tmp', '--single-process', '--data-path=/tmp/data-path', '--disk-cache-dir=/tmp/cache-dir']
This thread on the serverless-chrome github project discusses the issue and provides some binaries which I have used to capture screenshots of WebGL content on AWS Lambda using Page.captureScreenshot().
https://github.com/adieuadieu/serverless-chrome/issues/108#issuecomment-416494572
(See comment by #apalchys on 28th August)
This particular example uses SwiftShader which seems to be the preferred option going forward.
Note, however, that I was unable to create PDFs using Page.printToPDF() using this version - WebGL content just appears blank/white. However, I was able to also get Page.printToPDF() using an earlier version which uses osmesa, see https://github.com/adieuadieu/serverless-chrome/issues/108#issuecomment-371199530
We recently decided to integrate Material Design into our mature GWT application and this has finally forced our hand on moving from Legacy dev Mode to Super dev mode. We have this working fairly well using Chrome and Intellij IDE, 2016.2. One lingering problem though is viewing Java containers (Lists, Maps, etc.) in the debugger. In the screenshot below, the two expanded supportingCopyWidgetPresenters and supportingCopyEventPageBlockContentElements are both declared as java.util.Lists:
In case this is hard to read, the debugger is showing both lists values to be:
array = Internal error: com.google.gson.JsonParseException: Expected BEGIN_ARRAY but was BEGIN_OBJECT at line 1 column 1386
Is there a special argument I need to pass to super dev mode to have it interpret Lists (and Maps, for that matter) correctly in the debugger? Is this a matter of telling super dev mode to use a different JSON parser?
Any help is greatly appreciated!
This was an issue with the version of Intellij. This was answered in the GWT google group.
I have an app in which the app bundle contains an image file (I mean that the file is dragged into XCode and appears in "Other Sources"), and I am using code like:
[[NSBundle mainBundle] pathForResource:#"Auto" ofType:#"jpg"]
to get a path to the image.
I found that when running on a device (iPod Touch), the name is case-sensitive, so that if the file is "Auto" and I use "AUTO", the poath returned is "file://(null)". However on the simulator, if I use "AUTO", it works the same as if I use "Auto".
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug. Do the more experienced users out there think that it is, and that I should report it to Apple?
Thanks.
The iOS-Filesystem is case-sensitive, whereas the OSX-Filesystem the Simulator uses isn't.
You have to be very careful with this, I've shot myself in the foot with this more than once.
This has more to do with NS/CFBundle itself than it does with the underlying file-system:
Directly from Bundle Programming Guide: The Bundle Search Pattern:
Important: The bundle interfaces consider case when searching for resource files in the bundle directory. This case-sensitive search occurs even on file systems (such as HFS+) that are not case sensitive when it comes to file names.
You should always, always be assuming case-sensitivity. Well, perhaps a better way to express that is to say, never assume Case-insensitive-while-case-preserving (which is what HFS+ is). In the not-so-distant future, case-sensitive HFS+ could become the default format for Mac OS X. (In general, it would be preferred over the current case-preserving HFS+, but if Apple were to switch it now, there would likely be hundreds of thousands of apps that would break because of developers who made assumptions they shouldn't have. The iPhone is a clear example of the preference for case-sensitive HFS+. With no legacy programs to worry about, the iPhone has always been case-sensitive).
You are editing your code and resource names right now, so take the time to assure they match.
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug.
In general, this does not necessarily indicate a bug.
Do the more experienced users out there think that it is, and that I should report it to Apple?
Yes. But the bug has nothing to do with the device at all. Specifically, the bug is simply "Simulator file paths are not case-sensitive". If you can reproduce this in a "sandbox" project, do so, and submit it along with your bug report.
In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?
You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.
You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:
An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.
The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:
-ms-, mso- Microsoft
-moz- Mozilla
-o-, -xv- Opera Software
-webkit- Apple
-khtml- KDE
There are also some you might have never even heard of:
-atsc- Advanced Television Standards Committee
-wap- The WAP Forum
Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.
In recent years, all major browsers have adopted this as a de facto standard.
How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.
In the case of the border-radius rule you have a stable fallback.
How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.
The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):
=border-radius(!radius)
-moz-border-radius= !radius;
-webkit-border-radius= !radius;
-khtml-border-radius= !radius;
border-radius= !radius;
We can now write this everywhere:
.stuff
+border-radius(15px);
This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).
You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.
I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.
border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later.
So if you wish to have support for safari 3+ you have to use -webkit-border-radius