|
See my previous response. Where is the dialog?
|
|
|
|
|
Richard,
The function that I am trying to get to execute is COpenGLControl::oglInitialize() which was called in OnInitDialog in the example template I am following. the oglInitialize function, listed below should setup the OpenGL context. But my case is somewhat different as you can see from my most recent post and I don't know where to place the call to oglInitalize()
void COpenGLControl::oglInitialize()
{
static PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,
32,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
16,
0, 0, 0, 0, 0, 0, 0,
};
hdc = GetDC()->m_hDC;
m_nPixelFormat = ChoosePixelFormat(hdc, &pfd);
SetPixelFormat(hdc, m_nPixelFormat, &pfd);
hrc = wglCreateContext(hdc);
wglMakeCurrent(hdc, hrc);
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClearDepth(1.0f);
glFrontFace(GL_CCW);
glCullFace(GL_BACK);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
OnDraw(NULL);
}
In that example template I have three classes CMFCOpenGLDlg : public CDialogEx COpenGLControl : public CWnd and CMFCOpenGLApp : public CWinApp in this example the CMFCOpenGLDlg::OnInitDialog() function calls COpenGLControl::oglCreate() and COpenGLControl::OnCreate() calls COpenGLControl::oglInitialize() but I just don't see how to wire this up in my splitt form example where the panes are created from the splitter class.
Thanks,
John
...
// Create OpenGL Control window
m_oglWindow.oglCreate(rect, this);
|
|
|
|
|
OK, but you are not calling this from a dialog, but from a CView, so you probably need to call the initializer from the CView::OnInitialUpdate[^] function.
|
|
|
|
|
Richard,
Thanks for bearing with me. I looked in MDN and found this comment about OnInitialUpdate
Called by the framework after the view is first attached to the document, but before the view is initially displayed. So I assume that OnInitalUpdate is called automaticaly and I don't need to do anything to invoke it but where would I put the override code in CFormRight : public CFormView or COpenGLControl : public CWnd ?
Thanks again,
John
|
|
|
|
|
Member 12282738 wrote: CFormRight
Yes.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Member 12282738 wrote: So I assume that OnInitalUpdate is called automaticaly and I don't need to do anything to invoke it but where would I put the override code in CFormRight : public CFormView or COpenGLControl : public CWnd ?
Yes, it is called automatically. Note that if you do not override the OnInitalUpdate in your derived class then the base class implementation will be called.
And note, that OnInitalUpdate is a method of a CView, not a CDialog. So - override it in CFormRight class.
|
|
|
|
|
Member 12282738 wrote: ...I don't know where to place the call to oglInitalize()
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hello,
I am having trouble with my current project and need your help.
Weight sensor is is connected to arduino uno board and to several light sources.
goal is: sensor activated-mode1, sensor unactive-mode 2 for 5 seconds.
Mode 1 is blinking light and mode 2 is normal light.
I have written code sensor activation, for mode1 and mode 2 but it cant get it to work. What im i missing?
sensor :
(www.elecrow.com/weight-sensor-kit-3kg-p-883.html)
code:
sensor activation:
#include <Hx711.h>
#define LED 6
#define ADC1 A2
#define ADC2 A3
#define THRESHOLD 100.
Hx711 scale(ADC1, ADC2);
void setup() {
pinMode(LED, OUTPUT);
}
void loop() {
digitalWrite(LED, HIGH);
delay(500);
if(scale.getGram() > THRESHOLD)
digitalWrite(LED, LOW);
delay(500);
}
mod1 blinking
int led = 13;
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500); // wait
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(500); // wait
}
mod 2 light for 5 sec
int led = 13;
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH);
delay(0);
digitalWrite(led, LOW);
delay(5000);
}
|
|
|
|
|
Member 12403121 wrote: What im i missing?
The correct forum, perhaps.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
The above code means very little. Please explain exactly what the problem is. If necessary use your debugger to capture more information.
|
|
|
|
|
Member 12403121 wrote: but it cant get it to work
Does it compile? If not, what's the compiler error message?
Or if it does at least partially work, what does work, what does not?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Hi,
Sorry for not beening specific, i am new to this.
the problem is the first part of the code, one for interact with sensor. I dont know how to write it. This is my best try... it is modification of several examples. I was hoping for some advices.
code for mode 1 and 2 work Just fine i Just cant connect it all for sensor to recognize.
hope i explain it better tjan last time
|
|
|
|
|
The only thing I can see change between the two modes is the delay
int led = 13;
int mode = 1; static int delay1[2] = {500, 0}; static int delay2[2] = {500, 5000};
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH); delay(delay1[mode-1]); digitalWrite(led, LOW); delay(delay2[mode-1]);
if (mode == 1) mode = 2; else mode = 1;
}
In vino veritas
|
|
|
|
|
I have an application in which time values are transferred byte-by-byte to an Arduino via USB/COM. I have now realised that using CTime objects will suffer from the 19 January 2038 problem where, after this date, GetTime() will return negative values due to the return value being signed. It appears that use of COleDateTime with CTimeSpan ::GetTotalSeconds will avoid this as the return value is an unsigned quantity.
I have now written a bit of test code comparing CTime and the ColeDateTime. /CtimeSpan combination. Whilst the values returned by the various member functions (year, month, etc,etc) all give identical values, the GetTime() and GetTotalSeconds() values differ by 3600 (1 hour)
Here is my test code:-
CTime tNow;
tNow = CTime::GetCurrentTime();
int iTimeYear = tNow.GetYear();
int iTimeMonth = tNow.GetMonth();
int iTimeDay = tNow.GetDay();
int iTimeHour = tNow.GetHour();
int iTimeMinute = tNow.GetMinute();
int iTimeSecond = tNow.GetSecond();
unsigned long ulNow = tNow.GetTime();
COleDateTime epoch(1970,1,1,0,0,0);
COleDateTime tCurrentTime;
tCurrentTime = COleDateTime::GetCurrentTime();
int iOleYear = tCurrentTime.GetYear();
int iOleMonth = tCurrentTime.GetMonth();
int iOleDay = tCurrentTime.GetDay();
int iOleHour = tCurrentTime.GetHour();
int iOleMinute = tCurrentTime.GetMinute();
int iOleSecond = tCurrentTime.GetSecond();
unsigned long ulOleTime = (unsigned long)(tCurrentTime-epoch).GetTotalSeconds();
Doug
|
|
|
|
|
one hour difference between CTime and COleDateTime is because COleDateTime ignores daylight saving time
i would not care much about 2038, because today's code will be antique at that time
if these time values will be shared across multiple devices then i would use CRT functions
time_t now = time(NULL);
|
|
|
|
|
Hi Serkan,
I thought that originally, but COleDateTime MUST be taking account of DST as the GetHour() function returns the correct value. Thinking about it overnight, I'm beginning to think that I should have applied DST when generating epoch - that would fit the symptoms, wouldn't it ?
(The Arduino works with an unsigned quantity, so it will not be a problem !)
After thought:-
I now believe that the problem is due to taking the DIFFERENCE between Current Time and epoch (I actually got this code off the internet, but didn't do much thinking about it !!!) If DST is applied inherently to all OleDateTime objects, then taking the difference effectively removes any adjustment due to DST, So that would account for it for GetTime() and GetTotalSeconds() being 3600 seconds different !!
Doug
modified 28-Mar-16 5:01am.
|
|
|
|
|
ColeDateTime stores a time stamp value without information about time zone and DST. It is up to you to know if the value is local time or UTC. If you use COleDateTime::GetCurrentTime to initialise it, it will hold a local time value. If you use the constructor or assignment operator accepting a time_t or _time64_t value, it will be UTC when the time_t value has been retrieved using time() and not adjusted afterwards.
If you need to store time stamp values for later use, store them as UTC. This avoids wrong values and simplifies calculation of time spans. If you need to display times as local times, perform the conversion just before display.
See also Time Format Conversion Made Easy[^] here at CP.
|
|
|
|
|
Hello Jochen, I was not aware that the timestamp obtained from COleDateTime would depend on how the object was initialised. Therefore in my test code the object epoch would result in a UTC value, whereas that obtained from the other object (which initialised via GetCurrentTime()) would be localtime. This then blows my "difference" explanation as to why the result from CTime is 3600 seconds different from the COleDateTimeSpan object. My Arduino code expects time quantities to be received as localtime (i.e. adjusted for DST)
Doug
|
|
|
|
|
Still learning how to code wrote: My Arduino code expects time quantities to be received as localtime (i.e. adjusted for DST)
You should change that to UTC if possible. When your Arduino uses a different time zone than your Windows system, the results would be wrong again.
|
|
|
|
|
Reviewing some old projects I met a function like this:
bool func()
{
bool var = false;
if(...)
return var = false;
else
return var = true;
}
Actually what the function returns? I think true, because assigning can't be false.
VII. 36. When you surround an army, leave an outlet free. Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
RomTibi wrote: Actually what the function returns? I think true, because assigning can't be false.
There is an easy way to know !
- make a program that will execute that code.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Any assignment is also an expression which has the value of the assigned value.
if(...)
return var = false; else
return var = true;
Some programmers make use of this fact like this:
int x;
while ((x = SomeFunction()) > 0)
{
}
Whether or not this is good style is up to personal preference..
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
RomTibi wrote: I think true, because assigning can't be false.
True (regardless).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
|
RomTibi wrote: because assigning can't be false.
Of course it can. This is easy to test by writing a few lines of code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
