Is there a way to check what is the target of a link, using NSIS ?
[ I want to check and update links on desktop, but I have a hard time checking if they belong to my application, because the name may contain a space or something, so it may not be identical...
I also want to delete links that are no longer used, that point to my folder.
So... I would like to look at the target, but can't fins anything that gives it to me. ]
You could try the ShellLink plugin or call the IShellLink+IPersistFile COM interfaces directly with the system plugin but normally a uninstaller/updater will only deal with shortcuts it created and not things the user might have created/renamed...
Related
Not sure if this questions has been asked because I didn't know how to word the search. Please direct me if it has.
I am trying to add a feature to programs that I write to add a layer of protection incase programs end up with people that I do not want using it. I heard of a way to do this using a personal file located online (DropBox, GoogleDocs, etc). Your program checks this document for a 1 or a 0, etc. etc. etc.
I tried doing this with dropbox and google docs but really don't know how I would even start this to work consistently. Any help or initial direction on how to start this would be great. Thanks.
I am using the latest versions on 2sxc (11.05) and the Content App on DNN 9.06. The Content-Type for Locations does not have a field for Region (or State). Is there already something in place to account for that to get Canadian or US addresses to output normally? I realize I can add the field and then maybe use the Dropdown from Query to hook it up to DNN's list of Regions, and then modify the Views accordingly...
But that seems like a lot of work for something that might already be built in (and I just don't see it?). Or is there another easy way to tackle this?
Truth be told - we never needed that so far, so it doesn't exist.
Is this necessary for maps to work, or just another field which a standard us-address needs? I'm curious because neither outlook nor SharePoint seem to require such a field, so I never really thought about it.
BUT: if you do implement it, please do share it back with us, so we can publish it.
Note that if this is important, a possibly nicer solution would be to use a public api somewhere which provides this information, as it's most certainly more complete & up to date for this purpose. If this is the case, ping me and I'll implement a string-dropdown-from-json or something like that :)
I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.
I have been working on cleaning an old project's resource.h.
In the project I am working on, I have some IDs which are in the form:
IDM_XXXX 32771
but are referred in code in ON_COMMAND and ON_UPDATE_COMMAND_UI statements.
So am I right in thinking that they are following the command architecture and ideally should be named as ID_XXX instead of IDM_XXXX?
I have read through TN022: Standard Commands Implementation and see that Microsoft says:
We recommend you use the standard "IDM_" prefix for menu items which
do not follow the command architecture and need menu-specific code to
enable and disable them.
I am not sure what is meant by menu-specific code here.
How are IDM_XXXX resources normally handled? Also what is the valid range range for IDM_XXXX? I have gone through TN020: ID Naming and Numbering Conventions but am confused.
ID_ and IDM_ are interchangeable because commands are accessible via command bars, menus or maybe ribbons. I never use IDM_, I only use ID_
Reserved by the MFC is 0xE000->0xEFFF and 0x7000->0x7FFF.
TN020 says that menu/command IDs must be in the range of 0x8000 and greater, but I found no reason why to do this. In the tooltip handling and command routing of the dialogs of the 16bit MFC version and AFAIK an old MFC4.x version, there was a specific code that looks for commands being greater than 0x8000.
By accident I had cases were an ID <0x8000 was created, but it worked.
I would resist not following the recommendations in the technical note. Microsoft does have undocumented messages that may interfere with your code if you violate their recommendations. And, debugging such an issue would be difficult. Additionally, following the recommendation allows you the extra benefit of...
following the MFC command architecture not only makes command handlers
more powerful (since they will work with toolbars) but makes the
command handler code reusable
This means MFC will use the same code to handle any menu and toolbar interactions that are linked together.
I am trying to programmatic-ally set the Gnome 3/GDM 3 user profile/tile/face picture for a user's account in Gnome3/GDM. This is my first attempt at a simple program for Linux and I'm unfamiliar with the APIs and my searching has yielded little useful information. It seems like one can write data to a .face file but this doesn't seem to take affect (or perhaps my file type/specs are wrong). I found from this forum post that the information is stored in a user-specific directory under /var/lib/AccountsService/users, however I want my program to run with regular user privileges and writing (directly) to this file would require elevated privileges (despite an unprivileged user being able to specify an image for their account via the Gnome settings GUI).
Ideally, I would like to do the same for KDE/KDM and Gnome 2 versions as well. Any information would be greatly appreciated. Thanks!
OK, here's the part I can shed some light on:
On any Unix'y OS, you can always fall back on the GECOS field update function putpwent. Traditionally, the “Real Name” is the first part of the GECOS field in the user record, up to the first ,. Different systems store different extended information after the ,, including things like department names, home and office phone numbers and the like.
In Gnome 2, “they” used to use ~/.face as your personal face icon. However, there are all kinds of situations in which one user can't look into another's home folder (including root: things like network filesystems, encrypted loopback homes, and more), so this was abandoned at some point (I believe 3.0) in favour of the /var/lib/AccountsService/icons/$YOURNAMEHERE location.
In the spirit of Gnome 3, the new system (the one you most likely want to use) is the Accounts Services DBus service. You can obtain a user object over DBus, and alter it. The interface is org.freedesktop.Accounts / org.freedesktop.Accounts.User and has methods like SetRealName and SetIconFile. There are also a “bunch” of other methods for things like location, language, eMail, …
PS: you can also use libaccountsservice to interact with it without calling the DBus yourself. EG: void act_user_set_real_name (ActUser *user,
const char *real_name) and void act_user_set_icon_file (ActUser *user,
const char *icon_file) are exported from that library.
However, I don't know if K (or which version(s) of K) might be looking at this DBus service. So, if you really want to set up the K information, I'm afraid I don't know…
For what it's worth, you can also just let the user adjust it themself with
gnome-control-center user-accounts