Beginners question

[Falcon703549]

I'm struggling to put together a formula that will look at two fields and provide the correct link based on fields selected previously;


if ( [TBL_CONTACT.LL SERVER] == "License 2" ) {
return "https://web address.php";
}
else
{


The above works, I would like to develop this further......... If this field = "THIS" and THIS FIELD = THAT return THIS .....

if ( [TBL_CONTACT.LL SERVER] == "License 2" ) && [TBL_CONTACT.LL PRODUCT == "Version 4"] {
return "https://web address.VERSION4php";
}
else
{

I seem to be struggling with the addition of &&

 

[NoUserHere]

Wow you posted a link to an article that was published 9 years ago.

Indeed I did, I wouldn't have shared it if I thought it had no relevance. Lets sum this topic up...

My point still stands. Just because something is not supported, does not mean you can't use the language which their plugin targets. So now they don't allow you to automatically generate the code in VB, so learn to write it yourself. What's the big deal? You either obviously use an older version of their software with the example i posted (from ten years ago.) for a guide to get started. Or else stop quibbling about the fact that you now need to use C# to generate the code.

Once their plugin is CLS compliant (Common Language Specification). You can use either VB.Net or C# when interacting with their plugin and it makes no difference at compile as you only have IL. Take a look at what Microsoft says about CLS ::

To fully interact with other objects written in any language, objects must expose to callers only those features that are common to all languages. This common set of features is defined by the Common Language Specification (CLS), which is a set of rules that apply to generated assemblies. The Common Language Specification is defined in Partition I, Clauses 7 through 11 of the ECMA-335 Standard: Common Language Infrastructure.

If your component conforms to the Common Language Specification, it is guaranteed to be CLS-compliant and can be accessed from code in assemblies written in any programming language that supports the CLS.

So how is this a problem, I fail to see.

 

[NoUserHere]

If your component conforms to the Common Language Specification, it is guaranteed to be CLS-compliant and can be accessed from code in assemblies written in any programming language that supports the CLS.

I feel this also needs a little more clarity as so not to mislead you. Let me explain what the above means ::
When you create a project like VB.Net. That project compiles to one assembly and only one language, and this is because each project compiles to only one language by virtue of the compiler for that language compiler. So the above quote doesn't mean you can put a C# file in a VB.Net project, (well you could) but it won't do anything. But instead, you can use multiple assemblies in the same project solution, and each project can be coded in a different language because they are all compiled to MSIL by their appropriate compilers. Just like the diagrams below. Creating different assemblies/projects in different languages doesn't restrict you from interacting with a C# compiled DLL from a application created in VB.Net and vice versa.

Or the less extensive

Lets back up a bit. You said earlier ::

I am using a Plugin that has been developed to work in Sage Act, within that plugin scripts can be created previously in either VB or C#.
Following the latest update from Sage Act, only C# is supported, therefore I need to change my simple little script from VB to C#.
I'm not trying to learn C#, I have no interest, I had hoped some nice person would be kind enough to provide a simple correction or in plain English point me in the right direction,

If your project isn't to big, we can help you to translate it if you post the relative code for it. Or you can use an online converter, but they're not always reliable or perfect. Nobody here is refusing to help you, but you are refusing to help yourself by not following the pointers we are giving you.

You are not restricted to writing .NET assemblies in C#. You can use F#, IronPython, or VB.NET. Since you already know VB6 presumably, then the jump up to VB.NET shouldn't be too hard.

Are you willing to try or do you want to just park it here?

 

[Skydiver]

Based on the second link on post #15, I think the issue that our OP is not writing a plugin for ACT!. Instead he is relying on Durkin Computing's addon for ACT! called Impact Act!. I'm only guessing here, but it looks like what that addin does is allow the user to just write small snippets of C# or VB.NET and then Impact Act! will dynamically compile that code and load it into their addin to run against the main Act! product.

In this thread in the Act! Community, we see the initial report about Act! v21 having compatibility issues with code compiled by the VB compiler. It even has input from various ACT! plugin vendors, including Durkin Computing. While Act! developers are pointing their fingers at the Soraco, the provider of their licensing solution, it looks like Jim Durkin has made the decision to discontinue support for VB snippets in his addin.

My recommendation is that if you don't want to learn C#, then just use the various online VB.NET to C# converters that Jim Durkin provided on that link from post #15.

 

[NoUserHere]

Err Sorry if I misunderstood. Are you saying this is kinda a ACT! plugin for a ACT! extension of their actual application which the user has no control over which language they can use because the extension only parses the generated code in C# format from the ACT! plugin to the ACT! extension due to the latest version they released? I know that's a mouthful, and hopefully made sense Skydiver?

In which case, if I got that wrong, and the above is correct. The only other solution is to learn C# or convert VB.Net code to C# right? So this isn't as I thought on post 16/17?

 

[Skydiver]

Yes, post #16/17 are technically correct. VB.NET, C#, and the other .NET languages all compile into IL that is supposed to be language agnostic.

You and I were originally thinking that the OP was writing his own plugin. But based on that link above, apparently the OP is using a Act! plugin named "Impact Act!". Furthermore, SwiftPage, the current owners of Act! has gone dark regarding the bug where plugins compiled using the VB.NET compiler are failing to load because of the 3rd party product that Act! is using to enforce their licensing. They have not bothered to update the FAQ that I linked to in post #10, or respond to that thread that I linked to in post #18.

Based on the trailing part of the same thread from post #18, it looks like the "Impact Act!" plugin dynamically compiles VB.NET or C# code using the CodeDom namespaces. That was from three weeks ago. I think that James Durkin in his June release of the plugin has interpreted SwiftPage's silence on the issue as an implicit acknowledgement that VB.NET is not supported anymore. I'll leave it to you if you would come to the same conclusion.

It looks like Soraco, the producer of the licensing component, broke something in their code prevents the loading of IL generated by the VB compiler. Perhaps, as you noted above, Soraco's code is not CLS compliant anymore. Or perhaps Microsoft broke something in the .NET Framework -- the callstack for the crash shows the VB compiler crashing itself. What makes interesting is that the other thread noted that things still work on Win7, but not Win10.