Does anybody know, how Lightswitch's Application object can access shell object?
Application.Details.GetModel().Shell is type of - Microsoft.LightSwitch.Model.IShellDefinition {Microsoft.LightSwitch.Model.Storage.Shell}. But I need to access shell object, not its definition?
May MEF import/export is right way, but I don't know how.
Thank you.
Yes, that's the wrong type of shell. That refers to Shell extension type, which is one of the LightSwitch extension types for customising it. A Shell handles the layout of all of the controls of the application uses to display itself.
You need to use the AutomationFactory (which is only available for out-of-browser applications) to access the type of shell object that you're wanting:
If (AutomationFactory.IsAvailable = True) Then
Dim shell = AutomationFactory.CreateObject(APPLICATION_ID)
shell.ShellExecute()
End If
Related
I've been trying a solution for this, but. I cannot find it.
What I'm trying to do, is work with the "bind by reference" ability, but working with ILE RPG written with embedded sql.
I can use the BNDDIR ctl opt in my source. And everything works correctly.
But that means a "bind by copy" method. Checked deleting the SRVPGM and even the BINDDIR. And the caller program still works.
So, is there any way to use "bind by reference" in an ILERPGSQL program?
After my question, an example:
Program SNILOG is a module, that conains several procedures. Part of them, exported.
In QSRVSRC I set the exported procedures, with a source with the same name: SNILOG. Something like this:
STRPGMEXP PGMLVL(*CURRENT)
/************************************************** ******************/
/* *MODULE SNILOG INIGREDI 04/10/21 15:25:30 */
/************************************************** ******************/
EXPORT SYMBOL("GETDIAG_TOSTRING")
EXPORT SYMBOL("GETDIAGNOSTICS")
EXPORT SYMBOL("GRABAR_LOG")
EXPORT SYMBOL("SNILOG")
ENDPGMEXP
As part of the procedures are programmed with embedded sql, the compilation must be done with CRTSQLRPGI, using the parameter OBJTYPE(*SRVPGM).
So, I finally get a SRVPGM called SNILOG, with those 4 procedures exported.
Once I've got the SRVPGM, I add it to a BNDDIR called SNI_BNDDIR.
Ok, let's go to the caller program: SNI600V.
Defined with
dftactgrp(*no)
, of course!.
And compiled with CRTSQLRPGI and parameter OBJTYPE(*PGM).
Here, if I use the control spec
bnddir('SNI_BNDDIR')
, it works fine.
But not fine enough, as this is a "bind by copy" method (I can delete the SRVPGM or the BNDDIR, and it is still working fine).
When I'm not working with SQL, I can use the CRTPGM command, and I can set the BNDSRVPGM parameter, to set the SRVPGM the program is going to be called. Well, just their procedures...
But I cannot find any similar option in CRTSQLRPGI command.
Nor in opt codes in ctl-opt sentence (We have BNDDIR, but not BNDSRVPGM option).
Any idea?
I'm running V7R3M0 with TR level: 6
Thanks in advance!
the use of
bnddir('SNI_BNDDIR')
Is the way to bind by reference OR bind by copy.
The key is what does your BNDDIR look like?
If you want to bind by reference, then it should include *SRVPGM objects.
If you want to bind by copy, then it should include *MODULE objects.
Generally, you want a *BNDDIR for every *SRVPGM that includes the modules (and maybe a utility *SRVPGM or two) needed for building a specific *SRVPGM.
Then one or more *BNDDIR that includes just *SRVPGM objects that are used to build the programs that use those *SRVPGMs.
I have been banging up against this for several hours now and I'm hoping that someone can help point me in the right direction.
I'm developing a few custom PowerShell cmdlets, and one of the supporting classes is a User object. Several of my cmdlets either emit or consume List.
This has worked very well so far, but I hit a serious snag when I tried to serialize one of the lists. The export seems to work fine; I look at the file (csv, clixml, etc.) and it looks the way I expect it to with type User. However, when I re-import it, the type seems to change to CSV:Class.User or Deserialized.Class.User. Obviously, this causes a problem when it's fed into a cmdlet that expects the standard User class.
If there a good way to fix this? I suspected that changing my cmdlets to expect some Interface instead of List would probably do the trick, but I can't figure out what interface that should be. And I can find no switch to the import methods to specify class names.
Any help would be greatly appreciated.
Welcome to PowerShell's extended type system. :-) BTW you will also get back state-only deserialized objects when your objects are passed across a remoting session. You can query the PSObject's TypeNames collection looking for Deserialized.Class.User to determine if you have a deserialized version of your type. Sames goes for the CSV version. You could create a couple of factory methods or clone style constructors on your User class that takes a PSObject that is some type of User (CSV or Deserialized) and then create a regular Class.User object. Just be aware that certain operations may not make sense in the deserialization case. For instance, using a Process object as an example, you can call Kill on a Process object and if the object came from the same machine that would work (assuming correct privs). However, if you were to call Kill on a process object from another machine, that's not going to work - hence the special deserialized objects that are primarily just data (property) containers.
I'm coming across some strange MEF behaviour in Prism, which I can't really explain. I've found a way around it that I'm not too happy with, so I'd really like to understand what's causing it.
I've declared my shell window class with a PartCreationPolicy of NonShared. And I'm trying to use the CompositionContainer.GetExportedValue<>() function from my MefBootstrapper to create a new instance of the Shell.
The strange thing is, if I call Container.GetExportedValue<>() before the shell has been created, I get a new object of type Shell, each time I call it. However, once the shell has been initialized, repeated calls to Container.GetExportedValue<>() return the same instance of the Shell.
It's as if the shell initialization somehow re-registers my Shell export as a Shared.
However, I don't see any calls in the bootstrapper code that explicitly try to achieve this.
Can anyone explain:
what action has this side effect
How (if possible) to restore the NonShared behaviour, so I can create multiple shells using MEF/ServiceLocator.
Cheers,
Mark
I'm not sure how Prism uses MEF, but here's a theory: How is the shell being created in normal startup? My guess is that it is not by calling GetExportedValue from the MEF container, but rather by calling the constructor for the Shell and then adding it to the container via ComposeParts() or using a CompositionBatch. A part added directly to the container in that way would override what was available in the catalog, and the CreationPolicy wouldn't apply either (because MEF isn't creating that part).
here is a answer for your multiple shell question. you have to check if the NonShared behavior is answered there.
I'm doing an Eclipse RCP/Jface application, and I often use the MessageDialog.open... methods to show messages to the user.
However, the title for an information dialog, for example, is always the same. And the shell object provided, also, is always the top shell. As I wanted to keep my code DRY, I made some helper functions, which receive only the message as parameter. For the parent shell, I used PlatformUI.getWorkbench().getModalDialogShellProvider().getShell(). The documentation says that it returns "a shell ... that can be used to get the best parenting possible for a modal dialog" E.g.:
class Helper {
public static void openInformation(String message) {
MessageDialog.open(MessageDialog.INFORMATION,
PlatformUI.getWorkbench().getModalDialogShellProvider().getShell(),
Activator.translate("some.bundle.path.information"), message, SWT.NONE);
}
}
My question is why didn't they make the methods MessageDialog.open... to determine themselves the parent shell for the message? And am I missing something if I always use this same way to provide a shell for the message boxes?
My two cents,
It might have more than one Workbench Windows opened by your application. So passing in the shell of the window, it could help decide make which window be modal.
If you check the JavaDoc, you'll see that the shell may even be null. I believe the shell is only used to center the dialog (with respect to the shell).
I'm embedding Python into a C++ application. I plan to use PyEval_EvalCode to execute Python code, but instead of providing the locals and globals as dictionaries, I'm looking for a way to have my program resolve symbol references dynamically.
For example, let's say my Python code consists of the following expression:
bear + lion * bunny
Instead of placing bear, lion and bunny and their associated objects into the dictionaries that I'm passing to PyEval_EvalCode, I'd like the Python interpreter to call back my program and request these named objects.
Is there a way to accomplish this?
By providing the locals and globals dictionaries, you are providing the environment in which the evaled code is executed. That effectively provides you with an interface to map names to objects defined in the C++ app.
Can you clarify why you do not want to use the dictionaries?
Another thing you could do is process the string in C++ and do string substitution before you eval the code....
Possibly. I've never tried this but in theory you might be able to implement a small extension class in C++ that overrides the __getattr__ method (probably via the tp_as_mapping or tp_getattro function pointers of PyTypeObject). Pass an instance of this as locals and/or globals to PyEval_EvalCode and your C++ method should be asked to resolve your lions, tigers, & bears for you.