I have some serious trouble with Visual Studio, its driving me insane...
When a Class makes a new instance of another Class, I usually pass "this" to its constructor, and have an easy access to the parent Class.
parentPointer->myVariable
But with visual studio it just won't work.
I have the pointer, and i can access 8 million methods/variables, but just not my own public variables.
With the debugger i can actually see the variables and their values...
the structure looks like this:
parentPointer->MyClass::myVariable
So I can actually find the variables with that (weird) syntax. But then I get this error:
qualified name is not a member of class "CWnd" or its base class.
So I wasted one more hour on a super simple task with that Visual Studio...
(If it helps, its a MFC Application)
Any help would be highly appreciated!
Greetings
UPDATE
Ok finally got it...
I simply modified the new standard constructor:
newClass::newClass(CWnd* pParent, parentClass* parentPointer);
With the additional Parameter 'parentPointer' i can now use:
parentPointer->myVariable ! :)
I somehow thought it should automatically work with pParent...
(Its still pretty strange that with debugger I had all values ect. accessible in the pParent...)
PS: Thanks for making my Thread more readable, i still haven't figured out how to format it properly xD
Related
Up to now IntelliSense listed all public variables, methods and properties of a class, when I used the name somewhere else, but now it only shows a few properties and methods. The problem also occurs with forms and other controls.
There is a post, which dealed already with this issue (link to the post), but it does not provide a working solution. Maybe someone knows the reason for this behaviour.
Edit: Here is a screenshot with an example:
From your screenshot the problem is easier to spot. You are using the Default Instance of a form. As Hans said, intellisense not displaying here is a probably a minor bug that Microsoft will likely not fix. Your code is easier to fix however. Don't use the default instance; it should look like this:
dim f as new Form1
f.Sub1 '<--- should get intellisense here now.
You should avoid using default instance of forms. In my experience, they cause nothing but problems. Creating a form instance, storing it in a local variable or field, and passing those references around is easy enough. It's also a much better practice that will make your code stronger overall.
I'm a bit confused on exactly how the architecture for a VB.NET forms app actually works.
I've noticed in others' code, lines that read a little like this:
If frmMain.someBooleanProperty Then
but, I'm a bit confused because someBooleanProperty is then defined as an instance variable (i.e., as Public someBooleanProperty As Boolean in frmMain). How is it being referenced statically to access an instance variable? Is this just bad coding practice?
For reasons of backwards compatibility, VB.NET automatically creates an instance of every Form. This instance is accessible through a global property which has the same name as the Form class itself.
More details can be found here:
Why is there a default instance of every form in VB.Net but not in C#?
Trying to track down a COM problem, I'm debugging my code and seeming to see the same GUID represented different ways...
I have a line in our code:
class __declspec(uuid("{D4F83347-E58E-11d1-9D47-006008098294}"))
And various registry stuff in between, then a call to:
CLSID clsid;
::CLSIDFromProgID("myProgId",&clsid);
In the debugger, clsid is displayed as {000AFC9A-3347-D4F8-8EE5-D1119D470060}. To me this is too similar not to be right, but it's not something I can check automatically... we've got the D4F8 and 3347, 9D47, but E58E becomes 8EE5 etc.
Is there a way I can understand why this is happening, and a way I can get them to look the same for comparison?
EDIT
To clear up some side-tracking, I've checked and the CLSID in the Windows registry and our registration scripts is presented as {D4F83347-E58E-11d1-9D47-006008098294} too - so the issue over my uuid(...) is not relevant I think.
Using CLSIDFromProgID() when you already have the guid doesn't make much sense. The function looks in the registry to map the "ProgId" string to the CLSID {guid}. Which of course makes it important that the progid is registered properly. Sure sounds like it is not. When your class is already decorated with __declspec(uuid) then simply use the __uuidof() operator to retrieve the guid.
The similarity in the byte values suggests that your registration code is broken.
"__declspec(uuid" is only an association of the identifier to your class, nothing else. Using CLSIDFromProgID API you are resolving ProgID to CLSID using registration infromation in system registry. That is, the two don't have to match. They typically do match though if you do everything neatly and your COM class is registered with the same identifier as the one being attached in source code to the C++ class.
After some testing, I discovered that the issue was simply how the visual C++ debugger was displaying the value, nothing more. e.g the registry value is {D4F83347-E58E-11d1-9D47-006008098294}, calling ::StringToCLSID() on the result of CLSIDFromProgID() gives {D4F83347-E58E-11d1-9D47-006008098294} - but in the debugger MSVC++ displays the variable as {000AFC9A-3347-D4F8-8EE5-D1119D470060}.
Why it does that, is another question!
I'm trying to split some prior crafted code into a DLL. It's a simple logger system.
There are a few things that need to be shared with the main form in the project, so I set them up as a shared variable, but I don't use shared stuff often, and I worry it will cause variable conflicts regarding scope. I figured I would make a post here about it and see if someone can explain what I don't fully understand.
Since this is a logger it will be used a couple of places. Other DLLs that need logging may reference it through a instanced object and project reference. My main form will also have an instanced object and a reference to the logger libary.
Since one of my properties is a connection string and it's shared, does this mean that a instance of my logger class inside a DLL will have the same shared values as a instance on my main UI form? Or will the fact that the instance is inside of a DLL provide the scope boundary I need? I'm hoping it does..
I mainly worry that I might want to log using two different connection strings down the road.
(I hope my question makes sense. If it doesn't, post comments and I'll try to clarify.)
No, the fact that the instance is in a DLL does not provide the scope boundary you need. If the class or members in the DLL were declared static they would be shared and you could run into problems. So, just don't declare them static and be sure to create new instances of the object(s) when you consume them and you should be ok.
I have a VB6 dll that is trying to create a COM object using the following line of code:
Set CreateObj = CreateObject("OPSValuer.OPSValue")
However this fails with the error "Object variable or With block variable not set".
I can see OPSValuer.OPSValue in dcomcnfg and it appears to be registered fine. Does anyone have any ideas about what may be causing the problem?
It's possible that the class you are trying to instantiate is not installed correctly or is missing some dependencies. If you have access to OLE View, you can try instantiating that class outside of VB. If it won't instantiate then you have a bad installation or missing dependency. OLE View ships with Visual Studio, search for OleView.exe on your system.
It was located here on my system: D:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin
DMKing is right about OleView. Also try looking at the control in Dependency Walker, any missing dependencies should come quickly to the surface.
Since this is a DCom component there also may be something failing in the components constructor, if anything fails in the constructor you will get that error. Is this a local DCom object or something running on another tier?
Instead of CreateObject try instantiating it with a standard New and see if it gives you a different error. Adding the reference itself may help out with determining that error. Is there a reason you are using late binding, rather than early binding?
The error may be thrown within the object initializing routine. That I don't find "OPSValuer.OPSValue" on Google makes me think it is custom code that encounters a bug.
Assuming OPSValuer.OPSValue is a component written in VB, this is probably an error raised in the Class_Initialize event of that component. If you have the source code of the component it should be easy to debug.