When I'm in Access and using a Tab Control, if I copy a button on one tab and paste it to the same tab, this button becomes visible on all tabs. In fact, I think all controls do (I know it happened with buttons and labels).
Is there a way to fix this, or do I have to delete the copied controls and re-draw them on the tab they're supposed to be visible on? Is there a setting that fixes this? I've got a few pages where it'd be handy to be able to copy a chunk of controls and paste them onto a different tab.
This is an old issue that needs to be closed out. The OP #Johnny Bones talks about his answer in the comments but never posted what he did to fix it as an answer.
The answer is that the object was pasted in at the wrong level, the form level. Form level objects are seen on every Tab Page.
To fix this
Cut the object again
Select the Tab Page you want the object to live inside
Paste it there
Move it to the correct location
Related
I am using Google Analytics on a Sharepoint site. On the main page, we have an image in an image carousel that once clicked will bring you to a different page on the site. I have tried everything to track clicks on this image in GTM - click url, click ID, css selector, etc. I can not figure out why my trigger never fires. I have attached the
image, what pops up when I click inspect, and variables that show up with the click in GTM preview... (This is the second half of the variables in preview).Three images total.
Good job on including all the relevant debugging info.
Judging from your inspect, you're looking at the image.
However, judging from your click event inspection, the click lands on an a.
I don't see the a in your DOM on the screenshot, but it may be either dynamically added, or just outside of the screenshot.
No matter. Let's start to carefully debug it. Make a trigger that would be triggered on anything that matches a. That's just a debugging trigger. Make sure it triggers on your image clicks.
Now, let's just make a simple CJS variable that would console.log({{Click Element}}). No need to use it anywhere, just make it. Go to the debug view again, try clicking the banner again and look in the console for something that would look like this:
See that pretty element? Now the wonderful dev console allows you to copy JS path to this element and do whatever you want with it. Mainly, comfortably and quickly test CSS selectors against this element. I suggest changing the selector JS console generated. It should work (unless the page is too dynamic), but it would be fragile. Having the element, however, you'll be able to make your own selectors.
I was working with the ability to paste images into a div where it would then be uploaded via a post request. So far it seems to be working, but I noticed this toolbar that seems to show up when I make the content editable. As a result of this, the user is able to manipulate the div beyond just pasting an image which is what I do not want them to do.
<div tabindex="1" id="pasteZone" contenteditable="true" onkeypress="return false">
<span id="pasteMessage">Right click and paste an image, or click and press (ctrl+v for windows or ⌘+V for Mac)</span>
</div>
I need the paste zone to be editable so that the windows context menu allows for the option to paste the screenshot and have the option to ctrl+v or what have you. But I also do not want my users to be able to add text. It seems that I am able to do that successfully as far as key presses go, but the toolbar destroys that possibility.
What I have done:
I looked online to see if other examples of this occurred but I could not find anything on this particular issue. I checked to see if this was the standard for any contenteditable enabled div, but it is not. Other websites that have this do not show this toolbar.This leads me to believe that this has something to do with Bootstrap. If this is the case, how would I prevent this toolbar from showing?
Image:
So, I'm a little frustrated that someone in HR decided to force a .dotm template into my MS Word, which ultimately created a custom ribbon tab. This tab is annoying because it's not what I need, it's the first tab, and it's the default tab (instead of "Home"). They've also locked out the associated .dotm file from modification or moving.
Are there any other methods to remove (or at least move) the tab? I was thinking there might be VBA code to force some changes every time MS Word is opened. This would allow the tab, but then immediately move/remove it.
Ideas?
Thanks!
Brian
Whenever I click the "Home" option on my menu (left hand side, frames), a second copy of the menu page appears on the left side of the main window. The html of this link is identical to the other links, which work fine. As I'm just developing the site at the moment, the HTML of all the links is also identical. There is no code difference between this link and the others in any way, only the behavior.
The doubled copy of the menu is a phantom. It will not double itself again, and goes away when any other link, other than the home page, is navigated to. I'm currently in school and this is my first ground-up project, so I'm sure it's something stupid and simple.
Well Aarron, your problem is indeed quite obvious. After looking for hours, the solution the whole time is that your "Home" link is pointed at Index.aspx, which is the page with your frames, instead of Main.aspx. You were thinking of Index as your home page, which it is, but linking there in this context gave you frames within frames, instead of the default opening display page you were aiming for.
Sometimes a user will click on a link on a page, and it seems that there is no reaction -- nothing is loaded. It turns out that all the links on that page is targeting a window name, such as "news_content". The user previously already clicked on a news headline, and so when the user now clicks on another news headline, that window (usually another tab nowadays) will load the news, but the original tab is still the one being shown. To the user, this seems like nothing is happening.
Are those websites using <a href=" ... " target="news_content"> ? Is it a good idea to use something like that, or can it be changed a little bit so that the focus will go to that tab instead of staying at the original tab?
(is it better that the browser always switch to the target tab? if so, then this problem looks like will be solved).
In my opinion the user should always be in control of whether a link opens in a new window or not - If they're anything like me with numerous tabs endless new windows links are a mess.
What you seem to be asking is why the browser stays at the original page when a tab is updated with content, its simple, it sees it as another webpage, say you had a page that had realtime updating, your browser would not switch to that as it sees you are on another page - for all it knows you could be reading an article, watching a video etc.
All it takes to realise a different tab/window has updated is a little bit of awareness. With windows they would generally open over the current content, however as tabs are in one window this is not possible an it remains closed, but updated.
EDIT: In response to the title... I believe it to be better practice than opening something brand new each time however feel it should be the users choice whether to load a single new tab or stay in the same one. Hope this helps.
One caveat to add to the conversation.
I only use target= when I know the content is destined to be in an iframe and I don't want the link click to stay in the small window.
For example the graphs I embed here : http://webnumbr.com/stackoverflow-questions
Link behaviour should generally be left to the user to control. In some situations, a case can be made for target="_blank" (especially now that Firefox, at least, has a "New pages should be opened in: A new tab" option), but setting all links to open in the same new window is just bad.
I, for example, hate waiting for pages to load, so I'll read down a page middle-clicking each link that interests me, which will queue them up in a series of new tabs. Five interesting links become five tabs, each loaded in the background while I'm reading the first article, so no waiting. If you make all five open in the same window/tab, though, then each one disappears when I call up the next and not only do I have to 'pick one, wait for it to load, read it, go back to the original article, repeat', but, if I don't notice that this is what's happening, then I'll also need to go back and make a second pass through the original page to re-find the links to the lost documents (or, more likely, just say "not worth my time" and never read them).
Forcing newly-opened tags to the front has a similar problem: I opened it in a new tab because I want it to load in the background while I continue reading the original document. Don't subvert my intention. I cleared the "When I open a new tab, switch to it immediately" checkbox for a reason.
Yes, these websites are using target. Well. I can't imagine in which set of circumstances using the target attribute may be useful. But perhaps there's one. I haven't come across it.
Look, always switching to another tab solves the problem you describe, but it creates others. The biggest one is that switching to another tab may come as a surprise. Usability is by and large about never surprising the user. By the way, I greatly enjoyed the book "Don't make me think."