I use DOORs regularly, however, on a module that is rather large in size the auto scrolling feature takes 5 mins to scroll up and down the module to find its matching link within the other module I have open.
For example: Window A (module 1) & Window B (module 2)
I have Module 1 open on the left and module 2 open on the right. I am scrolling through module 2 to find the info I am looking for and at the same time module 1 is auto scrolling to keep up with matching the information that is linked.
This causing the SW to crash, freeze, take forever to scroll and lock me out etc.
Does anyone know of a way to turn this off? so I can freely use IBM DOORs without the auto scroll/auto match feature?
I have looked through all the setting within DOORs and have not found anything pertaining to this.
Related
It was easy when the Windows' explorer was using a SysListView32 control for displaying its files list as opposed to the DirectUIHWND control in the subsequent versions of Windows after XP.
A simple task such as obtaining the 'hot item' which is that item (a filename) the mouse hovers above for some hundreds of milliseconds, where before I could use the macros
ListView_GetHotItem with ListView_GetItemText and be able to obtain the filename under the mouse cursor.
This simple task becomes almost impossible to do with the DirectUIHWND window unless I revert this control back to a
SysListView32 which I have seen being proposed as the only solution on the many sites I have searched, and even if used the change does not occur immediately but only after I navigate out of the folder first.
It has taken me almost 2 years trying to find a solution to this and until now I feel stumped.
Anyone any idea please ?
Basically I have subclassed the parent of the tooltip and intercepted the tooltip notifications and all I need is the filename and the full path of the item the mouse hoovers above it, the hot item.
https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/march/windows-2000-ui-innovations-enhance-your-user-s-experience-with-new-infotip-and-icon-overlay-shell-extensions
IQueryInfo is required to provide the runtime text to the shell. IPersistFile is used by Explorer to let the extension know about the specific file currently under the mouse pointer.
With Cumulative Layout Shift (CLS) now a criteria of Page Speed Insights (PSI) and Google Search Console (GSC) I was wondering what method should be used in order to identify CLS if PSI returns a 0 value but Field Data returns a high value.
For example I have a page that scores 0 on PSI but gets 0.99 CLS for desktop (0 for mobile) according to Search Console.
Using Developer Tools I tried switching on paint flashing and switched on layout shift regions but still get 0 shift, whereas field data says 0.99.
So how do you identify what is causing a Layout Shift using developer tools?
So as nobody has answered this I will put down what I did, it may not be the best way to do it so bear that in mind!
I opened dev tools and setup a new profile under network speed where the latency was 1000ms and the speed to 50kb/s. (where it says "online" next to "disable cache", click there and go to "Custom > "Add...").
This effectively gives you time to see what is happening on a page as resources load in.
I then went to the "rendering" tab and switched on "Paint Flashing", "Layout Shift Regions" and "Layer borders"
I then just watched the page load with this artificial slow down in place.
It was immediately obvious doing this that I had a side menu loading in via AJAX but when it loaded it was about 1px too wide due to a border on it so it made the whole main section shift to the left a tiny bit.
Impossible to notice with the naked eye but really obvious with the above method. This didn't happen on the automated tests as it was (sort of) a race condition in a browser that depended on load order (using async for scripts as I do other manipulation on the aside) and PSI was consistent.
I hope this helps someone until someone comes up with a better way of identifying the root cause of a Layout Shift.
Update
As pointed out in the comments make sure you test at different screen sizes as well.
At the Developer tools, you can go to Performance > Record (the dot at the top). Then refresh the page by using a hard refresh (shift + refresh). NB: Best to make the developer tools sidebar as small as possible to simulate the correct browser size.
As the Developer tools is recording, you can scroll all the way down and stop the recording once you're at the bottom.
Resize the Developer tools tab, and a timeline will appear. This includes a section 'Web vitals'. At 'Experience', you will find blocks that indicate the Layout shifts.
If you hover over the Layout Shift box, the class will be visible in the webpage. You can even zoom in and hover over the timeline at the top, to see the layout at that specific time (and thus the difference in layout causing the layout shift).
If you click on the Layout Shift box, there's a summary in which you'll be able to see the changes e.g. 'Moved from Location [...], Size: [...x...]'
It takes some resizing between all the tabs in the Performance section, but for me, this is really helpful to find out what classes are causing these shifts! Hope this works for you as well.
Chrome DevTools can give you CLS measure and help you to debug pain-points of your website through:
Lighthouse
Performance panel
Red-tinted "Layout Shift" bar will drill you down into impacted elements
More read: https://web.dev/optimize-cls/
Some years ago (2008) I wrote an online Child Support Calculator using PHP/Javascript/Ajax/css Advanced Child Support Calculator - May help to explain what I am replicating.
Some time after (2009 I think) I started writing an equivalent for Windows and am now revisiting this. The fundamentals of this version are working.
However, I have an issue with the window noticeably flickering/changing when controls are dynamically added and the window is redrawn/rebuilt.
Note! This calculator is specific to Australia.
In short I'm looking for a way, if possible, to only refresh/re-display/redraw the window after all components have been added.
Basically, the windows controls need to be dynamically added/removed depending upon the scenario (number of adults and children involved).
Adding or removing a child or adult or performing the calculation, results in a complete rebuild of the window. That is, all existing controls are destroyed and then all valid controls are added (this could perhaps be minimised via complex logic).
The issue is that controls are removed but briefly reappear (in an ordered fashion) causing the display to flicker (for want of a better description).
The following screen shots demonstrate the complexity factor (such as a child has a drop down for each defined adult), but not the flicckering(sic).
Here's a screen shot of the Initial display (OK pretty ugly at present) :-
And then if an Adult is added (note that the child now has an extra dropdown for Adult 3, the new adult):-
And now, an Adult (as above) and a Child:-
Coding wise, there is a RebuildAll function. This has two main stages. (1) The removal of the controls. (2) The rebuild (recreation) of the appropriate of the controls (Create Window, SendMessage's and then ShowWindow)
At a minimum there are 61 controls. The number of controls is
23 + ((#children * 12) - 2) + (#children * (#Adults * 8 )) + ((#adults * 10) -4). It's likely suffice to say that the number of controls increases rapidly/exponentially.
I suspect that it might be possible to postpone the ShowWindow untill after all of the builds have been done. Is the solution, as simple (theoretically) as this, assuming that this is feasible or is there another way that would circumvent the need to change all the code to remove the 'ShowWindow' and add a ShowWindow at the end of the builds?
Note replacing the individual ShowWindow's with one significantly reduced the "flicker" but didn't eliminate it. (as per Update below).
As an endnote I'm pretty sure that something should be feasible as the
windows program I have to date is a very poor reflection of the speed
of the browser/javascript version, which basically does the same thing
on windows (albeit 64bit).
Update
I went through and commented out the ShowWindows in all the AddItem???? functions and added a ShowWindows to the function that calls all the functions. This has improved matters. However, the numerous DestroyWindow calls still causes flickering when removing all of the controls. So now I guess that I'm looking for something that can disable them apparently doing an equivalent of ShowWindow.
Update 2
I have found SendMessage(hwnd, WM_SETREDRAW, FALSE, 0); (TRUE to turn drawing back on). However, this appears to supress the DestroyWindow in that the display aspect of the control remains (the controls themselves don't appear to respond though).
By a process of elimination I have cured the flicker with a combination of ShowWindow's and WM_SETREDRAW's at pertinent points.
To briefly re-describe the issue. When adding a child or adult, or performing a calculation. The entire display is rebuilt. The rebuild basically consists of 2 phases. First, destroying the existing control windows and then adding the new/replacement set of window's controls.
The resolution was to :-
Issue a ShowWindow(hwnd,SW_SHOW); (for the main/containing
window) after all the pre-existing windows control's had been
destroyed.
Issue a WM_SETREDRAW FALSE message as per SendMessage(hwnd,
WM_SETREDRAW, FALSE, 0); before rebuilding the windows controls.
Without any ShowWindow's being used.
Build the windows controls via the various functions.
Finally, when all the windows controls have been built, issue a
ShowWindow(hwnd,SW_SHOW); (for the main/containing window).
Rather than seeing the controls appear and then disappear, "the flickering". The window is blank for a while and then the controls are displayed all at once.
I'm still confused about what is actually going on though, due to:-
After some thought I decided to use a MessageBox after all the destroys. When the message was displayed the window was blank. However, when the button was clicked and processing resumed then, in situations when the number of controls was relatively high, controls would appear and then disappear in an orderly fashion, albeit it momentarily.
My guess, is that creating a control in an area where an existing
control had been, was causing that previous control to momentarily
display.
I am making a program that sweeps software parameters of a DUT and logs measurements from various instruments while doing so.
To make this program more flexible, I want the user to be able to configure an arbitrary set of instruments (including multiple of the same kind) to log measurements from. Each instrument has different configuration parameters.
What i need is a dynamic UI, where I can add (and remove) Instruments and have a different configuration UI for each instrument.
I made a little sketch of what I have in mind: UI proposal
What I tried so far is to have an Array of a Cluster with a Subpanel in it, but all the Subpanels in the Array show the same VI.
A simple way of doing this is 2 subpanels. One stays on the main screen with your current vi running. When you want to switch vis load the new vi into the off screen subpanel. Move the positions of the subpanels so that the new one is on screen. Unload the old one and allow the new one to start. The old one is now ready for the next vi to run
Instead of a cluster or an array, the basic idea for making something like this work is to have one subpanel which will contain multiple subpanels inside it and populate/position/resize/show/hide them, etc.
See this thread for a discussion and a basic example I posted there - http://forums.ni.com/t5/LabVIEW/Independent-cursors-on-array-of-cluster-of-graphs-or-work-around/m-p/2319700#M728304
(Note - that thread shows a discussion and expansion on the topic. The original simpler example is here - http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599 )
While I always liked the idea of this, I never actually needed it for an actual UI, so I don't think I have anything to add beyond this example. Also note that the example is very crude and only meant to demonstrate this concept.
Note that there are two ways of handling the number of panels - have enough to be displayed and control which VIs they show based on the scroll bar or create "enough" subpanels and control their visibility.
I am trying to make a simple application in which there is a empty red rectangle and whenever the mouse is moved over the upper half border of the rectangle the cursor will become closed hand.
I started with selecting the foundation command line project.Made a transparent NSWindow and embedded a NSView in it with the rectangle, made window to accept mouse moved events(by method: -setAcceptsMouseMovedEvents). I have overridden -canBecomeKeyWindow and -canBecomeMainWindow window to return YES. But somehow none of the -mouseMoved events are being received by NSView.
When I put the same code by making a cocoa application project and creating my window in -applicationDidFinishLaunching method , my view was able to receive -mouseMoved events.
why is it not receiving mouse moved events when I use foundation command line utility project ?
I have also observed that whenever I make a window(carbon or cocoa) through foundation cmd line utility project , the window doesn't become key even on clicking the title bar.On clicking the title bar color remains light grey instead of becoming dark grey. Why is this happening?
I have overridden -canBecomeKeyWindow and -canBecomeMainWindow of NSwindow to return YES.
I would agree with what Joshua has already said. Any application that is going to show a user interface, be it a faceless background process or one which shows up in the Dock, should be in the form of an application bundle, not a plain old Mach-O executable like the Foundation tool template will create.
Also, there are reasons why views do not respond to mouseMoved: events by default:
Mouse moved events can quickly flood the event queue
There is generally little reason to use mouseMoved:, as tracking areas are
far more effective and efficient.
A while back, I wrote a little test app that demonstrates the differences between these 2 approaches:
Moving your mouse around the upper view for roughly 20 seconds results in 1000 events, while in the lower view, which uses tracking areas, less than 50.
Sample GitHub project: https://github.com/NSGod/MouseMoved-vs-TrackingAreas
Again, as Joshua mentioned, it would be helpful if you could describe what you're trying to accomplish. If your app needs to be a background app (LSUIElement == 1), and present an interface without appearing in the Dock, then there are ways to do that (as Josh mentioned, a command-line, non-bundled app is not the way).
You have no event loop to detect events and pass them to your window because your program does not start an NSApplication. See the main.m file of a typical Cocoa application.
It might be helpful to describe what you're trying to accomplish by taking this approach. My guess is you're building a daemon but want a GUI interface to manage the otherwise "headless" daemon. That or you're building a new login management system. In either case, there are specific ways to do both and this isn't it. :-)